记得刚学Java那会儿，老师总说Hibernate是神器，把数据库表映射成对象，写代码就跟玩似的。后来进了公司，发现项目里全是MyBatis，自己写SQL成了家常便饭。Hibernate好像慢慢被人忘了，我挺纳闷的，到底为啥？

我琢磨了一下，不是Hibernate不好，而是它太理想化了。它想让你忘掉数据库，用对象思维操作一切。可现实是，数据库才是爹，SQL才是跟它聊天最直接的语言。你让Hibernate自动生成SQL，它就像个不懂事的翻译，经常把话传错。

就说性能吧，Hibernate自动生成的SQL，在复杂查询时经常拉胯。比如多表关联、分组统计，它自己造出来的语句效率低得吓人，还容易搞出“N+1查询”这种经典坑。想优化？你都不知道慢在哪，因为它生成的SQL藏得深，你根本抓不到。

我有个同事，以前在传统企业做ERP，Hibernate用得很溜。后来跳槽去了互联网公司，发现那边根本不用Hibernate，全用MyBatis。他一开始不服，觉得Hibernate更高级。结果上线一个报表功能，Hibernate自动生成的SQL跑了十几秒，换成MyBatis手写SQL，一秒就出来了。

这就是现实。互联网公司追求的是性能，是能把控每一行SQL。DBA可以拿着MyBatis的SQL直接审查，哪里慢了改哪里。用Hibernate，DBA想看一眼都费劲，更别说优化了。

再说学习成本，很多人觉得Hibernate屏蔽了数据库，所以简单。其实恰恰相反，要真正用好Hibernate，你得搞懂一级缓存、二级缓存、查询缓存、Session管理、懒加载、事务传播……这些概念一个比一个绕。你花半年学这些，最后发现还不如直接写SQL来得快。

MyBatis就不一样，核心就是会写SQL。你只要会数据库查询，基本就能上手。学习曲线很平，性价比高。对于大多数普通程序员来说，这就是最实在的选择。

还有灵活性。Hibernate的自动机制有时反而成了枷锁。比如你想用MySQL的特定函数，或者写个窗口函数，Hibernate根本不支持，你得用原生SQL回退，那还不如一开始就用MyBatis。更别提存储过程了，Hibernate搞起来麻烦得要死。

反观MyBatis，SQL完全交给你，想怎么写就怎么写。业务变更快的时候，改个SQL比改对象映射快得多。互联网公司业务变动频繁，今天加个字段，明天改个逻辑，MyBatis改起来就是改一行SQL的事，Hibernate得重新映射，还可能影响其他功能。

其实Hibernate也有它的好，比如对象模型复杂、表关联多的企业级应用，Hibernate的自动化就很省心。像ERP、CRM这种系统，数据量不大，但业务逻辑复杂，用Hibernate能提升开发效率。但在国内互联网圈，大家更习惯“自己撸SQL”，这种务实心态让MyBatis成了主流。

有人说90%的公司放弃了Hibernate，这话有点夸张，但确实反映了趋势。阿里、京东这些大厂，内部数据量庞大，表结构经常反范式设计，为了性能宁愿冗余字段也不多关联。这种场景下，MyBatis直接写SQL是最合适的。

现在还有MyBatis-Plus这种工具，在MyBatis基础上封装了通用CRUD，既保留了SQL控制权，又简化了增删改查。这算是“半自动”的升级版，很受欢迎。未来可能还会出现更多混合模式，比如用JPA做简单操作，复杂查询走自定义SQL。

说到底，技术选型没有绝对的对错，只有合不合适。Hibernate的“理想主义”在设计理念上没错，但面对互联网的高并发、快速迭代，显得有点水土不服。MyBatis的“务实”更接地气，它让程序员把精力放在最核心的SQL上，而不是花时间研究框架的缓存机制。

程序员不是不爱Hibernate，而是MyBatis更懂他们每天面对的现实：要快、要稳、要可控。这不仅仅是框架的迭代，更是从“工具驱动”到“业务与性能驱动”的转变。未来ORM会怎么发展，谁也说不准，但有一点可以肯定：谁更尊重开发者的控制权，谁就能活得更久。