1. 为什么MyBatis能火这么多年先把优点说透“MyBatis有哪些优点和缺点”这个问题几乎每个做Java后端的人都被面试官问过。说实话这题目看起来像背八股但真要在项目里选型、排查性能问题、设计数据访问层时你会发现它其实是一道很现实的综合题——因为MyBatis的优点和缺点不是孤立的它们是一体两面的SQL可控性给你自由代价是半自动化的麻烦缓存机制提性能代价是脏数据风险。我这些年用MyBatis写过的SQL、踩过的缓存坑、调过的分页慢查询都能串到这个问题上。先聊优点。MyBatis最核心的优势就是“SQL可控”。相比Hibernate那种全自动ORMMyBatis把SQL完全交到你手里你能精确控制每一条查询语句。比如一条复杂的报表SQL要关联五六张表、带子查询和聚合函数Hibernate折腾半天可能还差强人意MyBatis里直接写原生SQL几分钟搞定执行计划还能用EXPLAIN一步步调优。这意味着在数据库性能优化、复杂查询场景下MyBatis几乎是碾压级的优势。其次是灵活的映射能力。MyBatis不要求数据库字段和Java属性完全同名你可以在resultMap里手动定义字段映射处理下划线转驼峰、嵌套对象、集合属性甚至连Oracle里的TIMESTAMP映射到LocalDateTime这种细节都能自定义typeHandler。我见过不少团队从Hibernate迁到MyBatis就是为了这张“映射自由”的牌。再说缓存。MyBatis自带一级缓存和二级缓存。一级缓存是SqlSession级别的同一个会话里执行同样的SQL第二次直接走缓存二级缓存是namespace级别的能跨会话共享。这在读多写少的场景里非常有用尤其是热点数据查询能明显降低数据库压力。配合Redis做分布式缓存之前MyBatis内置缓存可以先顶一阵子。最后是生态整合。MyBatis和Spring Boot结合得非常好起步依赖引入mybatis-spring-boot-starter配置mapper-locations指定XML路径一个Mapper接口就能被扫描到。再加上MyBatis-Plus这个增强包CRUD都不用写SQL分页插件也有了这大概就是为什么Spring Boot项目里MyBatis的占有率一直居高不下。2. 优点背后的代价MyBatis的缺点同样不可回避不要只盯着优点MyBatis的缺点在真实项目里一样扎手。2.1 半自动ORM带来的开发效率瓶颈MyBatis被定位成“半自动ORM”意思是它只帮你封装结果集映射但SQL、参数映射、结果映射的不少细节都要自己写。一个简单的单表CRUD如果你手写XML一个实体对应至少五个SQL标签insert、update、delete、selectById、selectList字段一多复制粘贴改字段名就够烦的。这也是MyBatis-Plus流行的原因——内置通用Mapper把基础CRUD包了但你自己不能永远靠Plus总会有复杂SQL要手写。而且由于SQL分散在XML或注解里你没法像JPA那样通过方法名推导查询IDE只能做很有限的校验。如果XML写错了列名编译期完全不管只有运行到那条SQL才报错。这种滞后反馈意味着测试成本变高。2.2 SQL散落与动态SQL的维护难题量大的项目里XML文件会迅速膨胀。我维护过一个老项目一个OrderMapper.xml堆了三四千行的动态SQLif、choose、foreach层层嵌套其他人根本不敢碰。动态SQL虽然灵活但可读性极差——你拼的条件越多越容易搞错逻辑而且XML里写复杂循环还特别不方便调试。这种情况下团队需要一个强约定SQL尽量按业务域拆分到不同Mapper动态条件要收敛避免在XML里写过于复杂的集合遍历和子查询。否则MyBatis的“灵活”就会变成“混乱”。说白了MyBatis对开发者的SQL功底要求很高不是“会写select * from就算会”。SQL写得不讲究的人用MyBatis只会把烂SQL扩散到每个角落。2.3 缓存机制的双刃剑效应优点里提到的缓存反过来看就是缺点。MyBatis的一级缓存默认开启但作用域仅限于SqlSession。在Spring里如果每次操作都用新的SqlSession一级缓存基本形同虚设如果有长事务里混着查询和更新还可能因为缓存没失效而读到旧数据。二级缓存如果配置不当比如缓存了查询结果但没配置更新后的清空策略很容易出现脏读。我见过一个事故一个报表查询走了二级缓存但后台数据是由另一个系统直接改数据库的MyBatis根本不知道数据变了结果报表页面连续三天数据不对。从那以后我对MyBatis二级缓存的态度就是单机、只读、可以开多数据源、外部写入、分布式环境坚决关掉把缓存交给Redis这种统一组件管。2.4 对开发人员SQL能力的隐性要求还是那句话MyBatis把SQL还给了你同时也把责任交给了你。同样的业务需求SQL写得差和写得好性能能差一个数量级。比如分页查询有人习惯先count再limit有人直接在select里写子查询看起来差不多但表大了以后执行计划完全不一样。还有批量插入很多新手用foreach一次性插几百几千条数据MySQL默认的max_allowed_packet可能直接爆掉。正确的做法是分批插入或者用ExecutorType.BATCH。这些经验都不是MyBatis帮你解决的它只是忠实地执行你的SQL。所以我经常跟团队说用MyBatis先练好SQL基本功不然工具越顺手坑挖得越深。3. 解密几个高频关键词背后分页插件、XML高亮、更新慢既然聊到实践我把大家搜索最多的几个MyBatis相关话题集中聊一下这些八成也是你面试或日常开发会遇到的。3.1 分页插件原理与用法PageHelper/MyBatis-Plus分页分页几乎每个项目必用。MyBatis本身没有内置分页功能需要自己拼LIMIT offset, size或ROWNUMOracle。现在主流方案是PageHelper或MyBatis-Plus内置的分页插件。PageHelper的原理很简单拦截Executor执行前的方法解析到当前线程上下文里的PageInfo参数自动改写原始SQL生成count语句和带分页的SQL。所以使用时要特别注意PageHelper必须在紧跟着的MyBatis查询方法前设置页码中间不能穿插其他查询否则会把无关的查询也当成分页执行。这个坑我踩过不止一次。Spring Boot集成PageHelper只需要引入pagehelper-spring-boot-starter然后配置一下helperDialect和reasonable参数。MyBatis-Plus的分页插件更简单配置一个MybatisPlusInterceptor注入PaginationInnerInterceptor然后直接用PageT对象作为第一个参数传给Mapper方法。它的好处是不像PageHelper那样有线程局部变量的副作用分页结果直接封装在Page对象里。代码示例// Spring Boot 中配置 MyBatis-Plus 分页插件 Configuration public class MybatisPlusConfig { Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor new MybatisPlusInterceptor(); PaginationInnerInterceptor pagination new PaginationInnerInterceptor(DbType.MYSQL); pagination.setMaxLimit(500L); // 防止一次拉太多 interceptor.addInnerInterceptor(pagination); return interceptor; } } // 使用 PageUser page new Page(1, 10); LambdaQueryWrapperUser wrapper Wrappers.lambdaQuery(); userMapper.selectPage(page, wrapper);实际项目中我建议给分页设置一个maxLimit上限避免用户传一个巨大的页码把数据库拖垮。分页插件还有一个隐患如果SQL里本身有GROUP BY或复杂的JOIN自动生成的count语句可能不准确你需要手动写count SQL。这就是典型的“工具兜底但你得知道它怎么兜”。3.2 XML编写与IDEA高亮配置、参数映射细节很多人问“MyBatis XML高亮怎么配置”其实IDEA对MyBatis XML已经有不错的支持装上官方插件或者直接用社区版就能识别mapper标签、select标签并给出SQL语句高亮。但要注意如果你在application.yml里没指定mapper-locationsIDEA编译时不会把resources下的XML打包进target运行时就会报“Invalid bound statement (not found)”。解决办法是在pom里配置资源过滤或者在application.yml里写mybatis: mapper-locations: classpath:mapper/*.xml type-aliases-package: com.example.entity configuration: map-underscore-to-camel-case: true log-impl: org.apache.ibatis.logging.stdout.StdOutImplmap-underscore-to-camel-case这个配置强烈建议打开不然数据库字段user_name映射不到userName。log-impl则让你能在控制台直接看到SQL和参数排查问题时比啥都灵。参数映射方面最常见的低端错误就是XML里写#{name}但Java方法参数没加Param(name)。如果Mapper方法有多个参数必须加Param否则MyBatis只能用param1、param2这种索引方式过两个版本就会出问题。我给大家一个习惯凡是Mapper方法参数超过一个统一加Param别嫌啰嗦。这是MyBatis面试题里特别爱考的“param index”问题。还有一个容易懵的场景动态SQL里的example.and。如果是用MyBatis Generator生成的Example类andXxxEqualTo这一串方法链经常把新手绕晕。其实它的本质就是一个可以拼接的条件构造器建议能不用Example就不用直接用MyBatis-Plus的LambdaQueryWrapper或者写XML自定义SQL可读性好太多。3.3 更新操作执行慢的排查实录热词里有个“mybatis update 执行慢”这种情况我遇到过两次。一次是更新语句涉及大表的未索引字段全表扫描加行锁竞争一看EXPLAIN就明白了typeALL、rows几十万。另一次更隐蔽接口上用Update注解写SQL但参数里传了一个非常大的对象MyBatis虽然只更新几个字段但日志里打印参数对象序列化都花了几十毫秒整体就变慢了。排查更新慢我一般按这个顺序来先看数据库慢查询日志定位到底慢在哪一步。用EXPLAIN看执行计划检查是否走了索引是否出现临时表、文件排序。看是否锁等待导致查information_schema.innodb_trx和sys.innodb_lock_waits。如果是大批量更新考虑分批提交避免一个事务锁太多行。检查Mapper方法参数是否过大尽量只传必要字段。其实MyBatis本身不会让SQL变慢它只是背锅侠。真正的慢根源永远是SQL写的、表结构设计的、事务控制的。你可以配置慢SQL监控比如MyBatis拦截器里打印执行时间超过阈值的SQL这样每天看一眼日志就能提前发现问题。3.4 源码阅读与二级缓存实现复盘思路如果你打算深度复盘MyBatis源码我推荐一个路径从SqlSession接口入手看默认实现DefaultSqlSession它持有Executor和Configuration。Executor分为BaseExecutor和二级缓存装饰器CachingExecutor。一级缓存在BaseExecutor的query方法里查localCache二级缓存则在CachingExecutor里通过TransactionalCacheManager维护。二级缓存实现的核心是PerpetualCache它本质就是一个HashMap配合LruCache等装饰器控制淘汰策略。缓存key是CacheKey对象由namespace sql 参数 环境等信息组成。当你调用update时BaseExecutor会调用clearLocalCache而CachingExecutor会清空对应namespace的二级缓存。这个机制看起来简单但分布式环境跨实例无效因为缓存只存在每个应用进程内存里。读完源码你就会理解为什么网上很多人建议直接用Redis缓存查询结果而不是依赖MyBatis二级缓存跨节点共享。读源码不需要从头到尾读按这条主线走就行配置解析XMLMapperBuilder→ Mapper代理生成MapperProxyFactory→ SQL执行Executor→ 结果映射DefaultResultSetHandler。基本就能把MyBatis的骨架理清楚了。4. 面试怎么答优缺点对比与选型建议既然标题叫优缺点面试答题的思路也顺带说一下。4.1 常见面试题拆解面试官问“MyBatis的优点和缺点”其实想考察你三个维度是否真实用过、是否理解ORM本质、是否有选型判断力。回答模板不用说什么“优点、缺点、适用场景”三段式而是要把优缺点和实际例子绑定。比如优点SQL可优化适合复杂查询。可以举例线上一个多表关联报表调用量大了以后我用MyBatis改写了SQL加了覆盖索引查询从2秒降到50毫秒。缺点半自动CRUD效率低但他可以补充说用了MyBatis-Plus提升开发效率。缓存能说清一级缓存和二级缓存的作用域和失效场景顺便提到生产环境用Redis代替二级缓存。这样会比干巴巴讲定义丰满得多。我记得有个面试者说“MyBatis的SQL和代码解耦DBA可以直接调优XML里的SQL”这个角度就很好说明他理解MyBatis在团队协作中的价值。4.2 MyBatis与MyBatis-Plus、JPA的边界面试时还经常被追问“MyBatis-Plus和MyBatis的关系”。MyBatis-Plus是在MyBatis基础上的增强包它没有改变MyBatis的底层机制只是提供了通用Mapper、条件构造器、分页插件、代码生成器等工具。用了MyBatis-Plus基础CRUD不用手写SQL但复杂查询你还是可以写XML。所以它不是替代MyBatis而是让MyBatis更好用。JPA则完全是另一种风格基于Hibernate的实体映射面向对象能力强CRUD开发效率极高但复杂查询和SQL优化空间小。我在小团队、原型项目里会用JPA快速迭代到中大型业务系统、报表和分析类场景我还是选MyBatis。选型没有绝对好坏关键看团队的SQL能力和项目复杂度。4.3 什么场景该选MyBatis什么场景慎选给你一个实际判断标准适合MyBatis数据库是Oracle、MySQL、PostgreSQL等关系型业务里有大量复杂SQL、报表统计、存储过程调用团队有专门DBA能帮调SQL项目需要精细控制SQL执行计划。如果你接的是传统金融、电商、SaaS后台MyBatis大概率是稳妥选择。慎用MyBatis纯CRUD管理后台几乎没有复杂查询团队成员对SQL不熟更习惯面向对象思维——这种项目直接用JPA能省一半时间。另外如果你的数据源是非关系型数据库MongoDB、ESMyBatis并不适配直接用自己的客户端或Spring Data就好。重要提示只要用了MyBatis一定要要求团队先过一遍SQL基础不然“所有问题都在SQL上”不是笑话而是事故。5. 我的实操心得与避坑清单这部分直接给大家上干货都是我实际碰过、调过的坑。5.1 配置打印SQL的几种方式查问题时第一件事就是看SQL。MyBatis打印SQL最简单的办法是在application.yml里配置log-impl: org.apache.ibatis.logging.stdout.StdOutImpl。但要注意StdOutImpl没有日志级别控制生产环境不建议开。更好一点的做法是用log4j2或Slf4j实现把com.example.mapper这个包下的日志级别设为DEBUG这样既能看SQL又方便用日志平台收集。在Spring Boot里还可以通过拦截器统一打印SQL和耗时。我写过一个简单的Interceptor重写Interceptor.intercept方法在invocation.proceed()前后记录SQL和执行时间。这种自定义拦截器比日志配置更适合做慢SQL告警因为你可以加上阈值判断。5.2 一个XML resultMap映射的坑多年前我接手过一个老项目查询用户订单列表订单里的userName一直是null。查了半天发现XML的resultMap里把userName映射成了user_name但实体类的属性是userName数据库字段是username。其实中间有个associaton子查询子查询的列名又起了别名三层嵌套后映射就乱了。所以写resultMap的时候一个原则是每个result column里的column必须是SQL查出来的别名而不是数据库原生列名。如果你SQL里写了u.user_name AS userName那么resultMap里应该写columnuserName propertyuserName。很多人混淆了“数据库列名”和“SQL别名”导致映射失败。5.3 国产数据库GaussDB下的MyBatis注意点热词里还有“mybatis 支持 gauss 吗”。实际上GaussDB的设计高度兼容PostgreSQL/OracleMyBatis配合JDBC驱动是可以用的但有几个坑分页语法可能和MySQL不同用limit的话要看版本序列的获取方式不同Oracle风格的dual表可能也一不一。我建议做国产数据库适配时把SQL方言抽出来用databaseId属性让MyBatis自动根据连接的产品名称选择不同SQL版本。MyBatis的DatabaseIdProvider可以在XML里通过databaseId属性指定这样同一段业务逻辑可以维护MySQL版和GaussDB版SQL。虽然麻烦但能在迁移时少掉不少头发。5.4 Oracle时间字段映射项目里用Oracle同时用MyBatis最经典的问题就是Oracle的DATE或TIMESTAMP映射到Java的LocalDateTime或Date。如果实体属性是java.util.Date一般没问题但如果是LocalDateTime就要注意MyBatis低版本可能不支持需要自定义LocalDateTimeTypeHandler或升级到MyBatis 3.4.5以上。还有一个坑Oracle的TIMESTAMP WITH TIME ZONE类型默认映射会丢失时区信息。我的做法是在SQL里直接CAST成时间戳字符串再让typeHandler转成OffsetDateTime一劳永逸。这些细节并不起眼但一旦到了生产环境就是“运行半年突然某条数据报错”的隐患。6. 一些关于MyBatis生态的个人经验最后再聊点关于生态的“软体验”。MyBatis到如今已经不单纯是ORM框架了它周围长出了一整套工具链MyBatis-Plus、MyBatis-Generator逆向工程、PageHelper、tk.mybatis、mybatis-mate、还有各种代码生成器。很多公司甚至把MyBatis和低代码平台结合在页面上配置SQL模板来动态生成Mapper。这说明MyBatis的生命力依然很旺盛尤其在国产化和传统企业级系统里。但值得警惕的是MyBatis的灵活性也容易导致SQL失控。我见过太多项目因为“MyBatis好写SQL”而把大量业务逻辑堆在SQL里几个大XML之间还要互相调用最后维护成本很高。比较好的实践是复杂统计SQL放进专门的报表Mapper基层CRUD尽量用MyBatis-PlusXML里的动态SQL控制在一个屏幕能看完的长度。如果超过这个长度拆方法或者拆到服务层用Java拼条件逻辑。我自己在实际项目中养成的习惯是开map-underscore-to-camel-case所有Mapper接口方法参数统一加Param所有XML的resultMap字段必须写别名对应所有查询都在测试环境用慢SQL日志跑一遍。这几个习惯看起来守旧但帮助我在无数个凌晨避免被线上SQL打爆。MyBatis的优势和劣势都摆在那里你要做的不是选一个完美的框架而是清楚手里的框架在什么场景下会把你带向哪里。 MyBatis优缺点深度解析：从SQL控制力到缓存与分页实践
1. 为什么MyBatis能火这么多年先把优点说透“MyBatis有哪些优点和缺点”这个问题几乎每个做Java后端的人都被面试官问过。说实话这题目看起来像背八股但真要在项目里选型、排查性能问题、设计数据访问层时你会发现它其实是一道很现实的综合题——因为MyBatis的优点和缺点不是孤立的它们是一体两面的SQL可控性给你自由代价是半自动化的麻烦缓存机制提性能代价是脏数据风险。我这些年用MyBatis写过的SQL、踩过的缓存坑、调过的分页慢查询都能串到这个问题上。先聊优点。MyBatis最核心的优势就是“SQL可控”。相比Hibernate那种全自动ORMMyBatis把SQL完全交到你手里你能精确控制每一条查询语句。比如一条复杂的报表SQL要关联五六张表、带子查询和聚合函数Hibernate折腾半天可能还差强人意MyBatis里直接写原生SQL几分钟搞定执行计划还能用EXPLAIN一步步调优。这意味着在数据库性能优化、复杂查询场景下MyBatis几乎是碾压级的优势。其次是灵活的映射能力。MyBatis不要求数据库字段和Java属性完全同名你可以在resultMap里手动定义字段映射处理下划线转驼峰、嵌套对象、集合属性甚至连Oracle里的TIMESTAMP映射到LocalDateTime这种细节都能自定义typeHandler。我见过不少团队从Hibernate迁到MyBatis就是为了这张“映射自由”的牌。再说缓存。MyBatis自带一级缓存和二级缓存。一级缓存是SqlSession级别的同一个会话里执行同样的SQL第二次直接走缓存二级缓存是namespace级别的能跨会话共享。这在读多写少的场景里非常有用尤其是热点数据查询能明显降低数据库压力。配合Redis做分布式缓存之前MyBatis内置缓存可以先顶一阵子。最后是生态整合。MyBatis和Spring Boot结合得非常好起步依赖引入mybatis-spring-boot-starter配置mapper-locations指定XML路径一个Mapper接口就能被扫描到。再加上MyBatis-Plus这个增强包CRUD都不用写SQL分页插件也有了这大概就是为什么Spring Boot项目里MyBatis的占有率一直居高不下。2. 优点背后的代价MyBatis的缺点同样不可回避不要只盯着优点MyBatis的缺点在真实项目里一样扎手。2.1 半自动ORM带来的开发效率瓶颈MyBatis被定位成“半自动ORM”意思是它只帮你封装结果集映射但SQL、参数映射、结果映射的不少细节都要自己写。一个简单的单表CRUD如果你手写XML一个实体对应至少五个SQL标签insert、update、delete、selectById、selectList字段一多复制粘贴改字段名就够烦的。这也是MyBatis-Plus流行的原因——内置通用Mapper把基础CRUD包了但你自己不能永远靠Plus总会有复杂SQL要手写。而且由于SQL分散在XML或注解里你没法像JPA那样通过方法名推导查询IDE只能做很有限的校验。如果XML写错了列名编译期完全不管只有运行到那条SQL才报错。这种滞后反馈意味着测试成本变高。2.2 SQL散落与动态SQL的维护难题量大的项目里XML文件会迅速膨胀。我维护过一个老项目一个OrderMapper.xml堆了三四千行的动态SQLif、choose、foreach层层嵌套其他人根本不敢碰。动态SQL虽然灵活但可读性极差——你拼的条件越多越容易搞错逻辑而且XML里写复杂循环还特别不方便调试。这种情况下团队需要一个强约定SQL尽量按业务域拆分到不同Mapper动态条件要收敛避免在XML里写过于复杂的集合遍历和子查询。否则MyBatis的“灵活”就会变成“混乱”。说白了MyBatis对开发者的SQL功底要求很高不是“会写select * from就算会”。SQL写得不讲究的人用MyBatis只会把烂SQL扩散到每个角落。2.3 缓存机制的双刃剑效应优点里提到的缓存反过来看就是缺点。MyBatis的一级缓存默认开启但作用域仅限于SqlSession。在Spring里如果每次操作都用新的SqlSession一级缓存基本形同虚设如果有长事务里混着查询和更新还可能因为缓存没失效而读到旧数据。二级缓存如果配置不当比如缓存了查询结果但没配置更新后的清空策略很容易出现脏读。我见过一个事故一个报表查询走了二级缓存但后台数据是由另一个系统直接改数据库的MyBatis根本不知道数据变了结果报表页面连续三天数据不对。从那以后我对MyBatis二级缓存的态度就是单机、只读、可以开多数据源、外部写入、分布式环境坚决关掉把缓存交给Redis这种统一组件管。2.4 对开发人员SQL能力的隐性要求还是那句话MyBatis把SQL还给了你同时也把责任交给了你。同样的业务需求SQL写得差和写得好性能能差一个数量级。比如分页查询有人习惯先count再limit有人直接在select里写子查询看起来差不多但表大了以后执行计划完全不一样。还有批量插入很多新手用foreach一次性插几百几千条数据MySQL默认的max_allowed_packet可能直接爆掉。正确的做法是分批插入或者用ExecutorType.BATCH。这些经验都不是MyBatis帮你解决的它只是忠实地执行你的SQL。所以我经常跟团队说用MyBatis先练好SQL基本功不然工具越顺手坑挖得越深。3. 解密几个高频关键词背后分页插件、XML高亮、更新慢既然聊到实践我把大家搜索最多的几个MyBatis相关话题集中聊一下这些八成也是你面试或日常开发会遇到的。3.1 分页插件原理与用法PageHelper/MyBatis-Plus分页分页几乎每个项目必用。MyBatis本身没有内置分页功能需要自己拼LIMIT offset, size或ROWNUMOracle。现在主流方案是PageHelper或MyBatis-Plus内置的分页插件。PageHelper的原理很简单拦截Executor执行前的方法解析到当前线程上下文里的PageInfo参数自动改写原始SQL生成count语句和带分页的SQL。所以使用时要特别注意PageHelper必须在紧跟着的MyBatis查询方法前设置页码中间不能穿插其他查询否则会把无关的查询也当成分页执行。这个坑我踩过不止一次。Spring Boot集成PageHelper只需要引入pagehelper-spring-boot-starter然后配置一下helperDialect和reasonable参数。MyBatis-Plus的分页插件更简单配置一个MybatisPlusInterceptor注入PaginationInnerInterceptor然后直接用PageT对象作为第一个参数传给Mapper方法。它的好处是不像PageHelper那样有线程局部变量的副作用分页结果直接封装在Page对象里。代码示例// Spring Boot 中配置 MyBatis-Plus 分页插件 Configuration public class MybatisPlusConfig { Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor new MybatisPlusInterceptor(); PaginationInnerInterceptor pagination new PaginationInnerInterceptor(DbType.MYSQL); pagination.setMaxLimit(500L); // 防止一次拉太多 interceptor.addInnerInterceptor(pagination); return interceptor; } } // 使用 PageUser page new Page(1, 10); LambdaQueryWrapperUser wrapper Wrappers.lambdaQuery(); userMapper.selectPage(page, wrapper);实际项目中我建议给分页设置一个maxLimit上限避免用户传一个巨大的页码把数据库拖垮。分页插件还有一个隐患如果SQL里本身有GROUP BY或复杂的JOIN自动生成的count语句可能不准确你需要手动写count SQL。这就是典型的“工具兜底但你得知道它怎么兜”。3.2 XML编写与IDEA高亮配置、参数映射细节很多人问“MyBatis XML高亮怎么配置”其实IDEA对MyBatis XML已经有不错的支持装上官方插件或者直接用社区版就能识别mapper标签、select标签并给出SQL语句高亮。但要注意如果你在application.yml里没指定mapper-locationsIDEA编译时不会把resources下的XML打包进target运行时就会报“Invalid bound statement (not found)”。解决办法是在pom里配置资源过滤或者在application.yml里写mybatis: mapper-locations: classpath:mapper/*.xml type-aliases-package: com.example.entity configuration: map-underscore-to-camel-case: true log-impl: org.apache.ibatis.logging.stdout.StdOutImplmap-underscore-to-camel-case这个配置强烈建议打开不然数据库字段user_name映射不到userName。log-impl则让你能在控制台直接看到SQL和参数排查问题时比啥都灵。参数映射方面最常见的低端错误就是XML里写#{name}但Java方法参数没加Param(name)。如果Mapper方法有多个参数必须加Param否则MyBatis只能用param1、param2这种索引方式过两个版本就会出问题。我给大家一个习惯凡是Mapper方法参数超过一个统一加Param别嫌啰嗦。这是MyBatis面试题里特别爱考的“param index”问题。还有一个容易懵的场景动态SQL里的example.and。如果是用MyBatis Generator生成的Example类andXxxEqualTo这一串方法链经常把新手绕晕。其实它的本质就是一个可以拼接的条件构造器建议能不用Example就不用直接用MyBatis-Plus的LambdaQueryWrapper或者写XML自定义SQL可读性好太多。3.3 更新操作执行慢的排查实录热词里有个“mybatis update 执行慢”这种情况我遇到过两次。一次是更新语句涉及大表的未索引字段全表扫描加行锁竞争一看EXPLAIN就明白了typeALL、rows几十万。另一次更隐蔽接口上用Update注解写SQL但参数里传了一个非常大的对象MyBatis虽然只更新几个字段但日志里打印参数对象序列化都花了几十毫秒整体就变慢了。排查更新慢我一般按这个顺序来先看数据库慢查询日志定位到底慢在哪一步。用EXPLAIN看执行计划检查是否走了索引是否出现临时表、文件排序。看是否锁等待导致查information_schema.innodb_trx和sys.innodb_lock_waits。如果是大批量更新考虑分批提交避免一个事务锁太多行。检查Mapper方法参数是否过大尽量只传必要字段。其实MyBatis本身不会让SQL变慢它只是背锅侠。真正的慢根源永远是SQL写的、表结构设计的、事务控制的。你可以配置慢SQL监控比如MyBatis拦截器里打印执行时间超过阈值的SQL这样每天看一眼日志就能提前发现问题。3.4 源码阅读与二级缓存实现复盘思路如果你打算深度复盘MyBatis源码我推荐一个路径从SqlSession接口入手看默认实现DefaultSqlSession它持有Executor和Configuration。Executor分为BaseExecutor和二级缓存装饰器CachingExecutor。一级缓存在BaseExecutor的query方法里查localCache二级缓存则在CachingExecutor里通过TransactionalCacheManager维护。二级缓存实现的核心是PerpetualCache它本质就是一个HashMap配合LruCache等装饰器控制淘汰策略。缓存key是CacheKey对象由namespace sql 参数 环境等信息组成。当你调用update时BaseExecutor会调用clearLocalCache而CachingExecutor会清空对应namespace的二级缓存。这个机制看起来简单但分布式环境跨实例无效因为缓存只存在每个应用进程内存里。读完源码你就会理解为什么网上很多人建议直接用Redis缓存查询结果而不是依赖MyBatis二级缓存跨节点共享。读源码不需要从头到尾读按这条主线走就行配置解析XMLMapperBuilder→ Mapper代理生成MapperProxyFactory→ SQL执行Executor→ 结果映射DefaultResultSetHandler。基本就能把MyBatis的骨架理清楚了。4. 面试怎么答优缺点对比与选型建议既然标题叫优缺点面试答题的思路也顺带说一下。4.1 常见面试题拆解面试官问“MyBatis的优点和缺点”其实想考察你三个维度是否真实用过、是否理解ORM本质、是否有选型判断力。回答模板不用说什么“优点、缺点、适用场景”三段式而是要把优缺点和实际例子绑定。比如优点SQL可优化适合复杂查询。可以举例线上一个多表关联报表调用量大了以后我用MyBatis改写了SQL加了覆盖索引查询从2秒降到50毫秒。缺点半自动CRUD效率低但他可以补充说用了MyBatis-Plus提升开发效率。缓存能说清一级缓存和二级缓存的作用域和失效场景顺便提到生产环境用Redis代替二级缓存。这样会比干巴巴讲定义丰满得多。我记得有个面试者说“MyBatis的SQL和代码解耦DBA可以直接调优XML里的SQL”这个角度就很好说明他理解MyBatis在团队协作中的价值。4.2 MyBatis与MyBatis-Plus、JPA的边界面试时还经常被追问“MyBatis-Plus和MyBatis的关系”。MyBatis-Plus是在MyBatis基础上的增强包它没有改变MyBatis的底层机制只是提供了通用Mapper、条件构造器、分页插件、代码生成器等工具。用了MyBatis-Plus基础CRUD不用手写SQL但复杂查询你还是可以写XML。所以它不是替代MyBatis而是让MyBatis更好用。JPA则完全是另一种风格基于Hibernate的实体映射面向对象能力强CRUD开发效率极高但复杂查询和SQL优化空间小。我在小团队、原型项目里会用JPA快速迭代到中大型业务系统、报表和分析类场景我还是选MyBatis。选型没有绝对好坏关键看团队的SQL能力和项目复杂度。4.3 什么场景该选MyBatis什么场景慎选给你一个实际判断标准适合MyBatis数据库是Oracle、MySQL、PostgreSQL等关系型业务里有大量复杂SQL、报表统计、存储过程调用团队有专门DBA能帮调SQL项目需要精细控制SQL执行计划。如果你接的是传统金融、电商、SaaS后台MyBatis大概率是稳妥选择。慎用MyBatis纯CRUD管理后台几乎没有复杂查询团队成员对SQL不熟更习惯面向对象思维——这种项目直接用JPA能省一半时间。另外如果你的数据源是非关系型数据库MongoDB、ESMyBatis并不适配直接用自己的客户端或Spring Data就好。重要提示只要用了MyBatis一定要要求团队先过一遍SQL基础不然“所有问题都在SQL上”不是笑话而是事故。5. 我的实操心得与避坑清单这部分直接给大家上干货都是我实际碰过、调过的坑。5.1 配置打印SQL的几种方式查问题时第一件事就是看SQL。MyBatis打印SQL最简单的办法是在application.yml里配置log-impl: org.apache.ibatis.logging.stdout.StdOutImpl。但要注意StdOutImpl没有日志级别控制生产环境不建议开。更好一点的做法是用log4j2或Slf4j实现把com.example.mapper这个包下的日志级别设为DEBUG这样既能看SQL又方便用日志平台收集。在Spring Boot里还可以通过拦截器统一打印SQL和耗时。我写过一个简单的Interceptor重写Interceptor.intercept方法在invocation.proceed()前后记录SQL和执行时间。这种自定义拦截器比日志配置更适合做慢SQL告警因为你可以加上阈值判断。5.2 一个XML resultMap映射的坑多年前我接手过一个老项目查询用户订单列表订单里的userName一直是null。查了半天发现XML的resultMap里把userName映射成了user_name但实体类的属性是userName数据库字段是username。其实中间有个associaton子查询子查询的列名又起了别名三层嵌套后映射就乱了。所以写resultMap的时候一个原则是每个result column里的column必须是SQL查出来的别名而不是数据库原生列名。如果你SQL里写了u.user_name AS userName那么resultMap里应该写columnuserName propertyuserName。很多人混淆了“数据库列名”和“SQL别名”导致映射失败。5.3 国产数据库GaussDB下的MyBatis注意点热词里还有“mybatis 支持 gauss 吗”。实际上GaussDB的设计高度兼容PostgreSQL/OracleMyBatis配合JDBC驱动是可以用的但有几个坑分页语法可能和MySQL不同用limit的话要看版本序列的获取方式不同Oracle风格的dual表可能也一不一。我建议做国产数据库适配时把SQL方言抽出来用databaseId属性让MyBatis自动根据连接的产品名称选择不同SQL版本。MyBatis的DatabaseIdProvider可以在XML里通过databaseId属性指定这样同一段业务逻辑可以维护MySQL版和GaussDB版SQL。虽然麻烦但能在迁移时少掉不少头发。5.4 Oracle时间字段映射项目里用Oracle同时用MyBatis最经典的问题就是Oracle的DATE或TIMESTAMP映射到Java的LocalDateTime或Date。如果实体属性是java.util.Date一般没问题但如果是LocalDateTime就要注意MyBatis低版本可能不支持需要自定义LocalDateTimeTypeHandler或升级到MyBatis 3.4.5以上。还有一个坑Oracle的TIMESTAMP WITH TIME ZONE类型默认映射会丢失时区信息。我的做法是在SQL里直接CAST成时间戳字符串再让typeHandler转成OffsetDateTime一劳永逸。这些细节并不起眼但一旦到了生产环境就是“运行半年突然某条数据报错”的隐患。6. 一些关于MyBatis生态的个人经验最后再聊点关于生态的“软体验”。MyBatis到如今已经不单纯是ORM框架了它周围长出了一整套工具链MyBatis-Plus、MyBatis-Generator逆向工程、PageHelper、tk.mybatis、mybatis-mate、还有各种代码生成器。很多公司甚至把MyBatis和低代码平台结合在页面上配置SQL模板来动态生成Mapper。这说明MyBatis的生命力依然很旺盛尤其在国产化和传统企业级系统里。但值得警惕的是MyBatis的灵活性也容易导致SQL失控。我见过太多项目因为“MyBatis好写SQL”而把大量业务逻辑堆在SQL里几个大XML之间还要互相调用最后维护成本很高。比较好的实践是复杂统计SQL放进专门的报表Mapper基层CRUD尽量用MyBatis-PlusXML里的动态SQL控制在一个屏幕能看完的长度。如果超过这个长度拆方法或者拆到服务层用Java拼条件逻辑。我自己在实际项目中养成的习惯是开map-underscore-to-camel-case所有Mapper接口方法参数统一加Param所有XML的resultMap字段必须写别名对应所有查询都在测试环境用慢SQL日志跑一遍。这几个习惯看起来守旧但帮助我在无数个凌晨避免被线上SQL打爆。MyBatis的优势和劣势都摆在那里你要做的不是选一个完美的框架而是清楚手里的框架在什么场景下会把你带向哪里。