共计 1501 个字符，预计需要花费 4 分钟才能阅读完成。
执行 sql 总览
首先还是来看下目前剖析的代码所处的地位，具体的代码如下：
之前也说过要应用 mybatis 操作数据库，在代码外面与 mybatis 相干的代码只须要三步：创立 SqlSessionFactory 对象，利用 SqlSessionFactory 对象创立 SqlSession，最初利用 SqlSession 执行 sql。到目前为止曾经剖析到最初一步，接下来详细分析 sql 是如果失去并执行的。
SqlSession 执行局部
上图能够看到即便调用的 selectOne 办法还是依赖的是 selectList 办法，而后依据查问后果的数量来判断，如果超过一条则间接抛出异样。我通过在 sql 中加 1 =1 or 测试的确是可能查出所有的数据而后报错。
这里实际上是我感觉不太好的实现，如果程序员不小心写错了 sql 在某种状况下能够查出多条甚至是全表，可能在测试环境没有测进去，而在线上环境呈现，那么将是对数据库和程序都是劫难，当然这种状况呈现的可能性特地小。而 mybatis 没有思考这种状况不晓得是不是因为是我了解不到位。
接下来看 DefaultSqlSession 的 selectList 办法，DefaultSqlSession 重载了三个 selectList 办法，最终都会调用参数最全的那个办法。这个办法只有两个要害步奏：首先通过参数 statement 从全局配置 configuration 获取到对应的 MappedStatement 对象，而后应用失去的对象和参数 parameter 调用 executor 的 query 办法。其中参数 statement 就是最开始传递的参数“com.itlezhi.mybatis.mapper.MemberMapper.getById”，parameter 对应参数 5。
通过这个办法应该可能彻底分明全局配置 configuration 的属性 Map<String, MappedStatement> mappedStatements 中 key 对应的是什么货色了。
executor 的 query 办法
执行器 executor 上一篇文章有剖析，默认是 SimpleExecutor 这个类，其中蕴含有全局配置 configuration 和事务 Transaction，而事务 Transaction 中有从 configuration 中失去的 DataSource，而 DataSource 中蕴含有数据库的连贯信息。他封装了一些数据库查问。不过下面说到的 query 办法属于根底办法，在 BaseExecutor 类中代码如下图：
最终还是来到 SimpleExecutor 这个类中，具体代码如下图：
外面的代码还是比较简单的，旁边我还写了一个间接应用 jdbc 查问的 demo 进行比拟，能够看到主流程曾经差不多统一，不同的点在于获取 connection 和对后果的解决。
获取 connection 是通过 BaseExecutor 的 getConnection 办法实现，实际上是调用的属性 transaction 实现，而 transaction 是通过属性 dataSource 来实现，这些都在上一篇文章中。
另外一个不同点就是对后果的封装，这个前面细说，这两个不同点也是应用 mybatis 的劣势之一。
总结
明天剖析的 sql 执行过程能够说是只从宏观下面进行了剖析，具体的实现细节并没有仔细分析，比方 sql 是如何失去的，参数如何设置的，后果又是如何封装了，能够说这些细节才是真正 mybatis 对应 jdbc 的劣势所在。不过先分梳理分明了主流程，接下来再来剖析具体的流程。
参考：《2020 最新 Java 根底精讲视频教程和学习路线！》
链接：https://juejin.cn/post/691225…
