请分析传统 JDBC 编程在开发过程中面临哪些主要问题，并阐述 MyBatis 框架针对这些缺陷分别采用了哪些解决机制？
考察说明
考查对 JDBC 痛点及 ORM/持久层框架优化思路的理解，评估对 MyBatis 核心设计目标的掌握程度。
回答思路
- 【回答框架 1】JDBC 的主要不足包括：样板代码多，需手动管理连接、Statement、ResultSet，导致开发效率低；SQL 与 Java 代码硬编码，改动需重新编译，可维护性差；结果集映射需要逐字段手工 get/set，繁琐且易错；无内置连接池和缓存，性能优化需自行集成。
- 【回答框架 2】MyBatis 的解决方式：通过 SqlSessionFactory 和 Mapper 接口，将 SQL 配置独立到 XML 或注解中，减少样板代码；提供自动参数映射和结果集映射，支持 resultMap 灵活转换对象；内置一级缓存（SqlSession 级别）和可配置的二级缓存，减少重复查询；可通过配置支持第三方连接池（如 HikariCP、Druid）。
- 【回答框架 3】MyBatis 保留 SQL 的灵活性和可控性，同时通过动态 SQL（if、choose、foreach 等）解决复杂查询拼接问题；与 Hibernate 的全自动 ORM 相比，MyBatis 更贴近 JDBC，适合 SQL 优化敏感的团队。
- 【回答框架 4】需要注意：MyBatis 并未完全消除 JDBC 的手动性，仍需关注连接的关闭、事务边界和缓存失效问题；其缓存是本地缓存，分布式场景需额外设计。
- 【关键点 1】JDBC 问题：样板代码多、SQL 与 Java 耦合、结果集映射繁琐、无内置缓存。
- 【关键点 2】MyBatis 通过 Mapper 接口和 XML 配置分离 SQL，减少重复代码。
- 【关键点 3】自动参数和结果映射简化数据访问，resultMap 处理复杂关系。
- 【关键点 4】内置一级/二级缓存，但需结合实际场景配置，分布式下需外部缓存。
- 【关键点 5】MyBatis 的动态 SQL 解决了复杂条件查询的拼接难题。
- 【易错点 1】误以为 MyBatis 完全没有 JDBC 连接管理责任，实际上仍需注意 SqlSession 的关闭。
- 【易错点 2】过度依赖 MyBatis 缓存，忽略数据一致性风险，例如多表更新时缓存失效未处理。
- 【易错点 3】把 MyBatis 与 ORM 完全等同，忽视其半自动特性，导致 SQL 控制能力减弱。