DefaultSqlSession不执行SQL，而是委托给Executor实例完成；其构造时初始化Executor（默认SimpleExecutor），所有CRUD操作均通过executor.query/update等方法调度，事务和缓存逻辑由执行器封装，SqlSession仅作为门面解耦上层调用与底层实现。
DefaultSqlSession 本身不执行 SQL，它把所有增删改查操作都委托给内部持有的 Executor 实例来完成。
执行器在 DefaultSqlSession 中的初始化
每次调用 sqlSessionFactory.openSession() 时，MyBatis 会创建一个 DefaultSqlSession 对象，并在构造时传入一个 Executor：
- 默认使用
ExecutorType.SIMPLE，对应SimpleExecutor - 该执行器由
Configuration.newExecutor(...)创建，封装了事务、一级缓存、Statement 生命周期等逻辑 -
DefaultSqlSession仅保存引用：private final Executor executor;
SQL 方法如何调度到执行器
以查询为例，selectList(String statement, Object parameter) 的流程是：
- 从
Configuration中根据 statement ID 查出MappedStatement - 调用
executor.query(...)，把MappedStatement、参数、分页等一并传入 - 执行器决定是否走一级缓存；若缓存未命中，则交由
StatementHandler执行 JDBC 操作
类似地，insert/update/delete 最终都调用 executor.update(...)；commit/rollback 直接转发给执行器处理事务。
立即学习“Java免费学习笔记（深入）”；
执行器类型影响底层行为
不同执行器对 JDBC 资源的使用方式不同，但上层调度逻辑一致：
-
SimpleExecutor：每次执行都新建PreparedStatement，用完即关 -
ReuseExecutor：按 SQL 字符串缓存PreparedStatement，复用已编译语句 -
BatchExecutor：将相同 SQL 的多次更新 accumulate 到 batch 中，flushStatements()时统一提交
这些差异完全封装在各自 doQuery/doUpdate 等模板方法中，DefaultSqlSession 无需感知。
关键点：解耦与门面模式
DefaultSqlSession 是典型的门面（Facade）角色：
- 对外提供统一、简洁的 CRUD 接口
- 对内只依赖
Executor接口，不绑定具体实现 - 执行器可被装饰（如加
CachingExecutor支持二级缓存），不影响 SqlSession 调用方式
