??SqlSession的生命周期管理核心问题??
为什么需要主动关闭SqlSession？当开发者未手动关闭SqlSession时，数据库连接池中的连接不会被及时释放，导致连接资源耗尽。特别是在高并发场景下，未关闭的连接会快速占满连接池，引发"Too many connections"数据库错误。通过try-with-resources语法或finally代码块强制关闭，可确保数据库连接100%回收。

如何选择SqlSession的作用域？在Web应用中应当优先使用请求级别作用域（request scope），每个HTTP请求创建独立的SqlSession实例。若错误使用全局单例模式，会导致多线程共享同一会话，可能引发事务混乱或数据覆盖。通过观察MyBatis日志中的connection ID变化可验证作用域是否正确。

??事务控制的关键场景实践??
如何实现多表操作的原子性？在批量插入订单和库存扣减场景中，必须显式调用commit()方法提交事务。典型错误是执行update操作后忘记提交，实际数据未持久化到数据库。建议采用统一的TransactionTemplate模板，在代码块内自动处理提交和回滚逻辑。

如何处理嵌套事务冲突？当外层事务已开启时，内层操作若错误开启新事务会导致"Transaction already active"异常。正确的做法是使用PROPAGATION_REQUIRED传播机制，复用现有事务。通过@Transactional注解的propagation属性配置，可避免事务嵌套引发的逻辑错误。

??性能优化的三大实现路径??
为什么批量操作必须使用BatchExecutor？默认的SimpleExecutor逐条提交SQL语句，执行1000次插入需要网络往返1000次。切换为BatchExecutor后，相同操作仅需1次网络传输，性能提升可达10倍以上。通过sqlSessionFactory.openSession(ExecutorType.BATCH)可获取批量处理器实例。

如何避免N+1查询问题？在关联查询场景中，错误写法会导致主查询产生N次子查询。正确方案是使用标签配置延迟加载（lazy loading），或通过复用公共SQL片段。通过EXPLAIN分析执行计划，可验证是否真正实现联合查询优化。

??连接泄漏的典型规避方案??
什么情况会导致连接未关闭？在foreach循环内频繁创建SqlSession却未关闭、异常分支未执行close()方法、使用ThreadLocal未及时清理等情况，都会造成连接泄漏。建议采用连接监控工具Druid的泄漏检测功能，当连接持有时间超过阈值时自动报警。

如何快速定位泄漏源头？在预发环境开启MyBatis的debug日志，观察Connection的open/close记录是否成对出现。生产环境可通过JMX查看连接池的activeCount与poolingCount数值变化，当activeCount持续增长但poolingCount不恢复时，即可确认存在泄漏点。

??缓存误用的防范策略??
为什么查询结果出现脏读？当两个SqlSession共享二级缓存且未设置flushCache="true"时，SessionA更新数据后SessionB可能读取到缓存旧值。关键配置是在/标签添加flushCache="true"，或在查询语句设置useCache="false"禁用缓存。

如何控制缓存更新粒度？全局缓存清空会导致性能骤降，正确做法是通过标签的eviction策略设置LRU淘汰规则。对于特定语句，使用@CacheNamespaceRef注解实现细粒度缓存管理。通过统计缓存命中率，可验证配置是否合理。

??异常处理的工程化实践??
为什么需要自定义异常处理器？当数据库主键冲突、字段超长等错误发生时，原生异常信息可能暴露表结构细节。通过实现MyBatis的ExceptionTranslator接口，可将底层SQLException转换为业务异常，同时记录完整的错误上下文到日志系统。

如何处理数据库切换异常？在多数据源环境中，错误的SqlSessionTemplate注入会导致事务管理器错位。正确的方案是为每个数据源创建独立的SqlSessionFactory，通过@Qualifier注解指定具体实例。在单元测试中使用@DynamicPropertySource验证多数据源切换的正确性。