MyBatis 与 MyBatis-Plus 核心区别总结
一、核心定位与底层关系
| 技术 | 核心定位 | 底层关系 |
|---|---|---|
| MyBatis | 半自动化 ORM 框架，主打"SQL 优先"，专注于 SQL 执行与结果映射，无内置通用 CRUD 能力 | 独立的持久层框架，是 MyBatis-Plus 的基础（MyBatis-Plus 完全基于 MyBatis 扩展） |
| MyBatis-Plus（MP） | MyBatis 的增强工具，在保留 MyBatis 原有特性的基础上，增加"无代码 CRUD""条件构造器"等能力 | 不是替代 MyBatis，而是兼容并增强 MyBatis，底层仍依赖 MyBatis 执行 SQL |
二、核心特性对比
1. 基础 CRUD 能力
| 维度 | MyBatis | MyBatis-Plus |
|---|---|---|
| 实现方式 | 需手动编写：Mapper 接口 + XML/注解 SQL（如 select * from user where id = ?） |
零 SQL 实现：继承 BaseMapper<T> 接口，直接调用内置方法（如 selectById(id)、insert(entity)） |
| 代码量 | 大（每个 CRUD 操作都需编写 SQL 语句） | 极少（通用 CRUD 无需写 SQL，仅需定义实体类和 Mapper 接口） |
| 扩展方式 | 完全自定义 SQL，无通用模板 | 内置通用方法覆盖 90% 场景，特殊需求仍可自定义 SQL（兼容 MyBatis 方式） |
2. 查询能力
| 维度 | MyBatis | MyBatis-Plus |
|---|---|---|
| 条件查询 | 需手动编写动态 SQL（<if>/<where> 等标签） |
提供 QueryWrapper/LambdaQueryWrapper 条件构造器，通过链式调用拼接条件（如 eq("age", 20).like("name", "张")） |
| 分页查询 | 需手动配置分页插件 + 编写分页 SQL（如 limit #{offset}, #{size}） |
内置分页插件，仅需调用 page(new Page<>(1, 10), wrapper) 即可自动分页，无需手写分页 SQL |
| 复杂查询 | 完全依赖手动编写 SQL（联表、子查询等） | 支持条件构造器结合自定义 SQL，也可通过 @SqlParser 等注解适配复杂场景，仍保留 MyBatis 原生 SQL 能力 |
3. 功能扩展
| 维度 | MyBatis | MyBatis-Plus |
|---|---|---|
| 代码生成 | 无内置生成工具，需依赖第三方（如 MyBatis Generator） | 内置 AutoGenerator 工具，可一键生成实体类、Mapper、Service、Controller 全套代码 |
| 主键生成 | 需手动指定主键策略（如自增、UUID），无内置封装 | 内置多种主键策略（@TableId(type = IdType.AUTO)/ASSIGN_ID 等），支持雪花算法自动生成分布式 ID |
| 逻辑删除 | 需手动编写 SQL 控制（如 update user set deleted = 1 where id = ?） |
配置后自动实现逻辑删除（查询时自动加 deleted = 0 条件，删除时执行更新操作） |
| 乐观锁 | 需手动编写版本号控制 SQL | 注解 @Version 即可自动实现乐观锁（更新时加 version = version + 1 条件） |
| 批量操作 | 需手动编写批量 SQL 或循环调用 | 内置 saveBatch()/updateBatchById() 等批量方法，优化批量操作性能 |
4. 开发效率与学习成本
| 维度 | MyBatis | MyBatis-Plus |
|---|---|---|
| 上手成本 | 中（需学习 XML/注解 SQL、动态 SQL 语法） | 低（会 MyBatis 即可快速上手，通用功能无需学新语法） |
| 开发效率 | 中等（重复编写 CRUD SQL 耗时） | 极高（通用操作零代码，复杂操作兼容 MyBatis 原生方式） |
| 维护成本 | 高（SQL 分散在 XML/注解中，实体变更需同步修改 SQL） | 低（通用 CRUD 无需维护 SQL，仅需维护实体类） |
| 兼容性 | 纯原生，无额外封装，适配所有自定义 SQL 场景 | 完全兼容 MyBatis 所有特性，自定义 SQL 不受任何限制 |
三、核心选择建议
- 选 MyBatis ：
- 项目需极致定制 SQL（如复杂联表、分库分表、SQL 优化要求极高）；
- 团队希望完全掌控 SQL 编写，避免框架封装带来的黑盒；
- 遗留系统仅使用 MyBatis，无需额外扩展能力。
- 选 MyBatis-Plus ：
- 追求开发效率，想减少重复的 CRUD SQL 编写；
- 项目以简单查询为主，复杂查询占比低；
- 需要快速生成代码、实现逻辑删除/乐观锁/分页等通用功能；
- 希望在保留 MyBatis 原生 SQL 能力的同时，获得类似 JPA 的便捷性。
- 核心原则 ：
MyBatis-Plus 是 MyBatis 的"超集"，选择 MP 不会丢失 MyBatis 的任何能力，仅需引入依赖即可无缝升级，是绝大多数基于 MyBatis 项目的最优解。
四、关键补充
- 依赖关系：使用 MyBatis-Plus 需先引入 MyBatis 核心依赖（Spring Boot 项目中，MP 提供
mybatis-plus-boot-starter，已内置 MyBatis 依赖，无需重复引入）； - 配置兼容：MP 完全兼容 MyBatis 的配置（如
mybatis.mapper-locations），仅需新增少量 MP 专属配置（如分页插件、主键策略）； - 核心接口：MP 核心是
BaseMapper<T>和IService<T>，前者提供单表 CRUD，后者提供更丰富的业务层方法（如批量操作、逻辑删除）； - 生态适配：MP 支持主流数据源（MySQL/Oracle 等）、分库分表框架（Sharding-JDBC），与 Spring Boot 无缝集成。