MyBatis 与 MyBatis-Plus 的区别

MyBatis 与 MyBatis-Plus 的区别

一句话总结

• MyBatis：更偏"SQL 映射器（SQL Mapper）"------SQL 基本由开发者编写，框架负责参数绑定、结果映射与执行。
• MyBatis-Plus（MP） ：在 MyBatis 之上做"增强"------不改变 MyBatis 用法与心智模型，但为单表 CRUD、分页、条件构造、代码生成等提供开箱即用能力，从而显著减少样板代码。

1. 定位与关系

• MyBatis 是基础持久层框架，强调 SQL 可控与灵活。
• MyBatis-Plus 是 MyBatis 的增强工具包：
  • 完全兼容 MyBatis（XML/注解、动态 SQL、插件机制等仍可照常使用）。
  • 引入 MP 后，你既可以用 MP 的通用能力，也可以在需要时回退到手写 SQL。

2. 核心能力对比（最常用维度）

维度	MyBatis	MyBatis-Plus（MP）
CRUD 开发效率	单表 CRUD 通常要写 Mapper 方法与 SQL（XML/注解）	提供 BaseMapper、Service 等通用能力，单表 CRUD 大多 无需写 SQL
条件构造	主要依赖 XML 动态 SQL（<if> / <where> / <foreach> 等）	QueryWrapper / LambdaQueryWrapper 链式构造条件，减少动态 SQL 拼装成本
分页	常见做法：集成 PageHelper 或自行实现	提供分页插件（通常为物理分页），配套 Page<T> 使用
代码生成	无内置	提供代码生成器，可生成 Entity/Mapper/XML/Service 等（适合快速搭架子）
字段与表映射	通常通过 XML resultMap/注解完成	提供 @TableName、@TableId、@TableField 等注解，映射更省事
主键策略	手动指定（如数据库自增、UUID 等）	内置 IdType 多种策略（具体枚举项随版本变化，不建议写死数量）
扩展方式	插件/拦截器（MyBatis 原生）	同样基于插件机制，并提供更多开箱即用拦截器能力
学习成本	需要掌握动态 SQL、映射规则	若已会 MyBatis，上手快；但需要理解 Wrapper、MP 约定与插件配置

3. 开发体验：什么时候更"爽"，什么时候反而不适合

3.1 MyBatis 更合适的情况

• 复杂 SQL（多表关联、窗口函数、复杂报表、存储过程、强提示的 SQL 优化等）。
• 需要对 SQL 执行计划/索引命中做到"像写 SQL 一样精确可控"。
• 团队规范要求：核心 SQL 走评审、沉淀为可读的 XML/SQL 文件。

3.2 MyBatis-Plus 更合适的情况

• 业务以 大量单表 CRUD 为主（典型后台管理系统、配置类系统）。
• 需要快速搭建项目、降低重复代码、统一分页与通用查询写法。
• 希望在保持手写 SQL 能力的同时，把"低价值重复劳动"交给框架。

4. 常见误区与注意点

1. "用了 MP 就不能写 XML/手写 SQL 了"：错误。MP 是增强，不是替代，你仍然可以在复杂场景使用原生 MyBatis。
2. "MP 自带 SQL 注入防护，所以可以随便拼 SQL" ：不要过度依赖。无论 MyBatis 还是 MP，核心仍应使用 #{} 参数绑定、避免字符串拼接；安全更多取决于编码规范与审计。
3. "MP 一定更快"：不一定。性能关键通常在 SQL 设计、索引与执行计划；MP 提升的是开发效率，并不会自动优化复杂查询。

5. 迁移与选型建议

• 新项目：如果 CRUD 占比高、追求效率，优先考虑 MyBatis-Plus；复杂 SQL 场景仍可混用 XML。
• 已有 MyBatis 项目 ：
  • 可以先从"分页/通用 CRUD"这类痛点切入，引入 MP 的插件与 BaseMapper。
  • 对已有核心 SQL 保持不动，逐步在新模块使用 MP 能力即可。

6. 小结

• MyBatis：SQL 灵活、可控、表达力强。
• MyBatis-Plus：在不牺牲 MyBatis 灵活性的前提下，显著提升单表 CRUD 与通用能力的开发效率。