MyBatis真的比Hibernate香？一个老码农的持久层选型实录
上个月组里来了个应届生，一上来就问我：“哥，咱们Java项目为啥不用JPA，非得用MyBatis？听说Spring Data JPA写起来贼爽。”我笑了笑，没直接回答，只是默默给他看了我们去年双11期间数据库慢查询日志——那会儿光是SQL优化就熬了三个通宵。作为一个在代码堆里摸爬滚打十几年、35岁还在敲键盘的老程序员，今天就想聊聊这个看似基础却关乎系统生死的问题：Java持久层框架到底怎么选？
被逼出来的技术选型
说实话，两年前刚进这个组的时候，我也对MyBatis有点抵触。之前在一家做区块链溯源系统的公司，后端清一色用Spring Data JPA，写个Repository接口加几个注解，CRUD直接搞定，简直不要太舒服。可到了现在这家公司，业务复杂度完全不是一个量级——每天几百万订单流水，用户行为数据要实时分析，还得对接一堆第三方支付和物流API。
产品经理上周五晚上9点甩过来一句“明天上线新促销活动”，我差点把咖啡杯捏碎。这种高压环境下，ORM框架能不能让你精准控制SQL，往往决定了你今晚能不能回家睡觉。而MyBatis，恰恰给了你这种“可控感”。
Python党的困惑与Java世界的现实
组里有个Python转Java的同事，刚来时一脸不屑：“你们Java怎么搞这么复杂？Django ORM一行代码搞定的事，你们要写Mapper、XML、POJO……”这话听着扎心，但他说的也没错——如果你只是做个内部管理系统或者小工具，Python + SQLAlchemy确实快如闪电。
但现实是，我们的系统要扛住高并发、要支持复杂的多表关联、要随时调优SQL性能。这时候，JPA那种“黑盒式”的SQL生成反而成了绊脚石。记得有次线上事故，就是因为JPA自动生成了一条带N+1查询的SQL，数据库CPU直接飙到90%，运维在群里@我：“老张，又来？”当时真的想砸电脑。
| 框架特性 | MyBatis | Hibernate/JPA | Python SQLAlchemy |
|---|---|---|---|
| SQL控制粒度 | 完全手动 | 自动为主，可HQL/原生 | 自动为主，可原生 |
| 学习曲线 | 中等（需懂SQL） | 较陡（需理解对象模型） | 平缓 |
| 性能调优 | 直接优化SQL | 需理解缓存和懒加载 | 类似Hibernate |
| 适合场景 | 复杂查询、高性能要求 | 快速开发、简单CRUD | 原型开发、中小项目 |
看明白了吧？不是MyBatis有多牛，而是它更适合我们这种“SQL即正义”的场景。
面试题挑战背后的真相
最近帮公司面试，问了个经典题：“MyBatis的#{}和${}有什么区别？”80%的候选人能答出前者防SQL注入、后者直接拼接，但当我追问“什么时候必须用${}”时，很多人就卡壳了。
其实答案很简单：动态表名或列名。比如我们有个需求，按月份分表存储日志（log_202403, log_202404...），这时候表名必须用${}：
<select id="selectByMonth" resultType="Log">
SELECT * FROM log_${month}
WHERE user_id = #{userId}
</select>
但这里有个大坑！必须自己做白名单校验，否则就是SQL注入的温床。我在代码里加了这样的校验：
public List<Log> getLogsByMonth(String month, Long userId) {
// 严格校验月份格式：必须是6位数字且在合理范围内
if (!month.matches("20\\d{4}") || Integer.parseInt(month) < 202001) {
throw new IllegalArgumentException("Invalid month format");
}
return logMapper.selectByMonth(month, userId);
}
这种细节，光背面试题可学不到，都是线上踩坑踩出来的。
从XML到注解：我的配置演进史
刚用MyBatis时，我也是XML党，觉得SQL和代码分离很优雅。但后来发现，小团队维护几十个XML文件简直是噩梦——改个字段要翻半天配置，IDE还不能自动提示。
现在我们组基本转向注解+少量XML混合模式。简单查询用注解，复杂动态SQL保留XML：
@Select("SELECT * FROM users WHERE status = #{status} AND create_time > #{since}")
@Results({
@Result(property = "createTime", column = "create_time"),
@Result(property = "lastLogin", column = "last_login")
})
List<User> findActiveUsers(@Param("status") int status, @Param("since") Date since);
对于需要<foreach>或复杂<if>判断的，还是乖乖写XML：
<select id="searchOrders" resultType="Order">
SELECT * FROM orders
<where>
<if test="userId != null">
AND user_id = #{userId}
</if>
<if test="statusList != null and statusList.size() > 0">
AND status IN
<foreach item="status" collection="statusList" open="(" separator="," close=")">
#{status}
</foreach>
</if>
</where>
ORDER BY create_time DESC
</select>
这种混合策略，既享受了注解的简洁，又保留了XML处理复杂逻辑的能力。而且配合Lombok，POJO类干净得让人感动：
@Data
@Builder
@NoArgsConstructor
@AllArgsConstructor
public class Order {
private Long id;
private Long userId;
private String orderNo;
private Integer status;
private BigDecimal amount;
private Date createTime;
}
区块链项目里的意外收获
去年参与一个区块链存证项目，需要把交易哈希批量写入MySQL。最初用JPA的saveAll()，结果批量插入10万条数据花了47秒。换成MyBatis的批量插入后，只要3.2秒！
关键配置就两点：
- 开启
ExecutorType.BATCH - 手动控制事务边界
@Autowired
private SqlSessionFactory sqlSessionFactory;
public void batchInsertHashes(List<String> hashes) {
SqlSession sqlSession = sqlSessionFactory.openSession(ExecutorType.BATCH);
try {
HashMapper mapper = sqlSession.getMapper(HashMapper.class);
for (String hash : hashes) {
mapper.insert(hash);
}
sqlSession.commit(); // 只提交一次
} finally {
sqlSession.close();
}
}
对应的Mapper方法：
@Insert("INSERT INTO block_hashes (hash_value) VALUES (#{hash})")
void insert(@Param("hash") String hash);
这个优化直接让我们的区块链节点同步速度提升了15倍。有时候真觉得，那些鼓吹“ORM万能论”的人，可能没经历过真正的数据洪峰。
给新人的三条血泪建议
别迷信“全自动”：MyBatis不是银弹，但它给你留了逃生舱口。当自动生成的SQL跑不动时，你能立刻切换到手写模式，而不是跪着等框架作者发新版。
XML命名要有规范：我们组约定
{EntityName}{Operation}{Condition}，比如UserSelectActiveByRole。别笑，这招让新来的实习生三天就能找到对应SQL。永远不要关闭日志：生产环境也开着
mybatis.configuration.log-impl=org.apache.ibatis.logging.stdout.StdOutImpl（当然要配好日志级别）。上次定位慢查询，全靠这行日志救了命。
最后说句掏心窝的话
35岁还在写代码，很多人觉得该转管理了。但我觉得，能把基础技术用到极致，也是一种竞争力。MyBatis看似简单，但里面的缓存机制、插件体系、类型处理器，随便挖深一点都是宝藏。
就像上周团建，领导喝多了拍我肩膀：“老张啊，咱们系统稳定全靠你这些‘老古董’。”我笑着回他：“等哪天MyBatis被AI取代了，我就去写Python。”
不过话说回来，要是Python能处理我们现在的并发量，我早就转了好吗！
评论 0