这标题其实就是我刚入行那会儿经常追问老同事的一句话。当时总觉得ORM层层封装、行为黑盒查个数据还得琢磨框架到底生成了什么鬼SQL远不如自己写两行来得踏实。直到后来把一个五十多张表的老系统从裸JDBC重构成Spring Boot MyBatis-Plus才明白一个道理项目里大量“直接写SQL”的代码其实是在用最低效的方式做重复劳动而ORM框架解决的根本不是“执行SQL”这件事而是“数据代码的工程化”这件事。这篇文章我就把这里的门道掰开了讲既有技术选型对比也有我自己踩过的慢SQL、N1、连接池之类的坑希望能帮正在纠结“框架还是原生SQL”的朋友少走点弯路。先说清楚这篇文章适合谁看。如果你刚接触Spring Boot、若依这类框架对Mapper、Entity、BaseMapper.selectList()这些概念半懂不懂不知道封装底层的SQL要怎么写那你大概率能用这篇文章搭起完整认知框架。如果你已经写了两三年SQL正处在看ORM很不顺眼的阶段那第二部分和第四部分的选型思路、场景取舍应该能对上你的胃口。如果你是架构选型负责人第六部分的排查速查表和常见坑可以直接当团队培训材料用。1. 先从真实业务视角回答“为什么不直接写SQL”1.1 一段让我彻底改观的线上事故先讲个真事。早几年我接手过一个对账系统账务明细、订单、退款、渠道流水好几张表之间关联特别密之前几任开发都是裸JDBC风格所有查询全写在Service里拼SQL全靠字符串拼接。表面上看着很“可控”每个SQL都五脏俱全。但有一次需求要新增一个“渠道类型”字段用来区分线上和线下订单。按常理只要改表结构、加个实体字段、改改涉及的对账查询就行。问题是退款明细和渠道流水两张表里压根没有这个字段而旧SQL里到处是LEFT JOIN嵌套LEFT JOIN结果集映射全靠手写ResultSet循环改漏一个地方就需要在几十个查询里追一次。联调当天还不明显跑批到凌晨两点对账平不了。爬起来查了半天发现是新增字段后某段SQL查询只带出了主单的渠道类型子单关联查询漏了条件导致两条子单落到错误的分组里。那一夜之后我就把ORM的正经价值彻底想明白了当业务规则长在代码里而不是仅仅长在SQL里时“直接写SQL”的维护成本远比你想象的高。这件事给我两个教训。第一手写SQL的本事必须练那是排查问题的底子。第二一旦业务复杂度和表数量上来“直接写SQL”会让字段变更变成一场灾难因为你很难在几十上百条SQL里快速抓住“哪条忘了加新条件”。1.2 你真正应该避免的不是SQL而是重复的机械映射后来我反思当时对ORM的反感其实停留在一种误解上以为ORM是在“取代SQL”。实际上Hibernate、MyBatis这类框架从来不是要替代SQL而是要把ResultSet与Java对象之间的双向映射、事务边界管理、连接获取与释放、脏数据检查等这些机械操作接过去。有一次我带新人重构模块让他统计一个月内的支付单。他二话不说写了三十多行JDBCgetConnection()、prepareStatement()、executeQuery()、rs.getLong(order_no)、手动if (rs.next())判断再手动拼成对象。我说你要真有耐心可以继续这么写但过两个月表加个字段你要把所有rs.getXXX()的地方翻出来改一遍。他抬头看了看我突然懂了——ORM收走的是这些毫无创造性但极容易出错的样板代码而不是收走你对数据关系的理解能力。一个特别贴切的类比是直接写SQL好比你现在下楼买菜路线自己定速度自己控灵活性很高。ORM则像是叫了个靠谱的代驾你只要说清楚目的地查询条件和偏好分页、排序、关联范围代驾自己会选路线。但代驾选的路不一定是最短最快的所以你仍然需要知道“大概怎么走”——这就是为什么懂SQL原理的人用ORM才顺手而完全不懂SQL的人用ORM会掉进N1查询和全表扫描的坑里。1.3 数据库可替换性带来的架构自由度还有一个不太好量化但影响很大的优势数据库可替换性。早期项目一旦深挖进LIMIT、TOP、NVL这类方言换数据库几乎等于重写数据层。ORM虽然做不到100%屏蔽数据库差异但至少分页、主键生成、基本类型映射这类最常见的差异框架已经帮你抹平了。我自己经历过的项目里就有一次活生生的案例。原来跑在MySQL上的系统因为客户内网要求换到PostgreSQL数据层代码基本没动只调整了方言配置、略微改了两处原生SQL的分页写法其余业务代码原封不动。要是当初几十个查询全部手写方言级SQL那周期就不是两三周能搞定的了。2. 主流ORM框架技术路线与选型思路2.1 全自动派JPA/Hibernate 系全自动ORM的代表是Hibernate以及建立在它之上的Spring Data JPA。这类框架的特点是你定义好实体类与表映射关系后框架通过持久化上下文自动管理对象状态。当你调用save()、find()时框架会自动生成SQL并且在事务提交前自动执行脏检查把改动过的字段同步到数据库。优点很明显日常CRUD开发效率极高代码写起来几乎跟操作普通Java集合一样自然。缺点也明显当查询复杂到一定程度自动生成的SQL可能不如你手写的优化尤其多表关联、子查询、窗口函数场景下生成了你真的看不懂的执行计划。团队里如果有人不了解底层懒加载机制还特别容易触发经典的LazyInitializationException。用我们一段真实经验说JPA系并不适合“报表密集、查询需求变化极快”的项目却非常适合“领域模型复杂、事务性操作多、对象关系密集”的系统。比如电商订单模型订单、明细、收货地址、支付单、物流单这些对象之间天然存在明显的聚合关系用JPA管理级联操作会非常顺手。2.2 半自动派MyBatis/MyBatis-PlusMyBatis走的是另一条路SQL还是要你自己写但参数映射、结果映射、动态SQL、连接管理交给框架。这种“半自动”的设计很符合国内大多数Java项目的实际口味因为它保留了SQL的透明性又消灭了大量样板代码。MyBatis-Plus则在MyBatis基础上加了BaseMapper、条件构造器、内置分页插件让单表CRUD都不用写SQL了。我在实际项目里用MyBatis-Plus最深的感受是它给了团队一个很清晰的底线。简单CRUD走框架内置方法复杂查询写XML里的SQL两条路随时可以混用完全没有什么心理负担。若依框架RuoYi这类国内脚手架默认配的也是MyBatis-Plus原因也很朴素——上手快、看得懂SQL、团队成员无论水平高低都不容易跑偏。2.3 技术选型对照表维度JPA/HibernateMyBatis/MyBatis-Plus直接JDBC开发效率单表CRUD极高高低复杂SQL掌控力弱需要JPQL或原生SQL兜底强XML里都能写最强对象状态管理自动脏检查、级联操作基本没有偏向手写完全没有学习曲线较陡缓存、懒加载概念多平缓核心就是Mapper平缓但繁琐数据库可替换性最好中等SQL方言还需注意最差适合场景领域模型复杂、事务操作密集互联网业务、快速迭代、报表极少一般仅局部使用选型没有绝对正确答案。我更愿意把JPA理解为“对象思维”把MyBatis理解为“SQL思维”。团队背景决定选型如果团队整体SQL功底扎实、业务又以查询为主MyBatis系通常更稳。如果团队领域驱动设计做得深、希望对象模型直接指导持久化设计那就认真学好JPA的缓存和懒加载机制别半吊子上车。3. 把ORMs的“基础设施”细节吃透再上手3.1 连接池与事务边界别把框架当保险箱很多人以为用了ORM连接管理就完全不用管了。这是最危险的误解。ORM只是封装了连接的获取和释放底层仍然依赖连接池。如果你用的是默认配置连接池参数不合理或者事务边界设计得乱七八糟性能照样崩。举一个我排查过的问题。某个挂牌系统上线后运行稳定但每到整点批量任务一跑前端操作就变得卡顿。查看监控发现不是慢SQL导致的而是数据库连接池被打满了。原因在于代码里有个Transactional注解挂在一个耗时很长的Service方法上方法内部还进行远程HTTP调用事务迟迟不提交连接一直被占用。这其实和用什么框架无关但ORM让“事务看起来太容易”这一点反而让人容易放松警惕。我现在的习惯是三条铁律Transactional只加在Service层需要原子性的方法上绝不往Controller层加。事务方法内不进行远程调用、文件上传、消息发送这类耗时操作。连接池参数初始值宁可给保守一些也要留出监控报警空间。3.2 实体设计与表结构之间的“翻译”实体设计是ORM项目中最需要投入精力的地方。一个经验不足的团队很容易把实体类和数据库表做成“一个Java类对一个表”的僵化映射。实际上更合理的方式是先梳理聚合边界哪些对象是一起读写的哪些只是查询展示用的哪些字段变更频率高哪些字段属于低频历史数据。举个具体例子。我们有个订单表字段一度膨胀到四十多个因为运营不停往里面塞新属性。后来我把高频交易字段留在主表把扩展属性拆成单独的JSON字段或扩展子表再用ORM的OneToOne、Transient等机制组织好读取路径。这样实体类不会变成一个无从下手的上帝类SQL执行的宽度也瘦身不少。实体设计还有个容易被忽略的点懒加载的使用原则。MyBatis-Plus里默认不搞懒加载那套查出来是什么就是什么反而是JPA里默认ToMany懒加载。使用JPA时如果你明确知道某个接口列表不需要引用明细数据就坚决别去碰getOrderItems()这类方法否则框架会在你毫不知情的情况下为每行数据发一条明细查询SQL。这个“看起来没事”的背后往往就是N1的温床。3.3 SQL日志与慢查询定位给ORM装上仪表盘既然ORM是帮你生成SQL的那么你就必须有能力看到SQL否则等于蒙眼开车。JPA系在配置里打开spring.jpa.show-sqltrue配合format_sqltrueMyBatis系可以在mybatis.configuration.log-implorg.apache.ibatis.logging.stdout.StdOutImpl打开控制台SQL打印。生产环境不建议直接打日志但至少保证在预发环境能随时开启。更关键的是线上数据库的慢查询日志永远比应用日志优先。我一般会同时做两件事把long_query_time设成1秒持续观察慢SQL再用EXPLAIN分析每一条被ORM自动生成的复杂SQL。尤其是MyBatis-Plus的QueryWrapper它生成的多表关联SQL有时会让你皱眉——不是不能用而是你必须掌握随时把它拿到Navicat里执行一遍并看执行计划的习惯。4. 那些年踩过的N1、分页和慢SQL的坑4.1 N1问题框架只走一条SQL实际发了一百条N1可以算ORM世界里名气最大的坑。典型场景是这样的你查一个班级列表框架发了一条SQL查出50个班级。然后在页面模板里遍历班级取每个班的班主任信息由于这段访问是懒加载框架又发了50条SQL查询班主任。加起来一共51条这叫N11条主查询N条关联查询。我在一个老项目里见过最夸张的情况是一张列表页面加载了三千多条SQL。当事同事特别委屈说自己只写了一行clazz.getTeacher().getName()。这正说明问题不出在SQL本身而出在对ORM懒加载机制的理解。解决思路一般有三条路批量抓取JPA里用BatchSize或EntityGraph把关联查询改成一次IN查询合并成少数几条SQL。查询时指定抓取MyBatis-Plus里直接用select注解写清楚要查询的字段或者手动JOIN好再映射避免循环里触发懒加载。转换DTO先查询出必要字段用Map批量匹配关联数据而不是在循环里逐条取数。一定要记住访问数据库的次数往往比单条SQL是否优化更影响性能。一次网络往返可能是0.5毫秒但三千次往返可能就是几十倍差距。压测时如果碰到吞吐量上不去建议先看应用日志里统计SQL次数而不要一上来就死磕单条语句。4.2 分页查询不同框架的不同应对法分页是最常见也最容易出错的场景。MyBatis-Plus自带分页插件用起来非常舒服但它底层还是通过拦截器改写SQL实现LIMIT。问题是当你分页的数据量特别大时比如几十万行LIMIT 500000,20这种深度分页扫描大量行再丢弃效率极低。我自己优化过一个案例用户操作日志表年增量几百万行后台管理页面点第9000页时数据库CPU飙到80%。后来改成基于游标的分页也就是前端把上一页最后一条记录的ID和创建时间传回来SQL改成WHERE id ? ORDER BY id DESC LIMIT 20这样数据库只扫描需要的范围性能立刻提升两个数量级。你要明白分页优化的核心从来不是ORM而是分页策略本身。ORM只是帮你把策略写得更省力而已。JPA分页则要注意Pageable对象虽然便捷但某些场景下框架会先发一条count查询再查数据。如果你的列表接口数据量本身就很大且不需要展示总条数可以考虑用Pageable.unpaged()或者直接返回Slice省掉count查询响应时间能有明显改善。4.3 慢SQL优化先看执行计划而不是先改代码很多朋友碰到慢SQL第一反应是换成手写SQL觉得“一定是ORM生成了垃圾SQL”。实际上我见过的案例里至少有一半问题不在SQL文本本身而在索引失效或查询条件设计上。包括隐式类型转换比如字段是varchar参数传了IntegerMySQL会放弃索引还有函数包裹索引列比如DATE(create_time) ?同样导致索引失效。我处理过一个线上单据查询页面输入起止日期后列表很慢。EXPLAIN一看查询确实走了主索引但过滤之后仍然要回表几百万行。最后把查询从“一个人在列表里直接大范围搜”调整为“先进入最近一个月的默认范围再用创建时间和状态联合索引过滤”查询时间从三秒降到一百毫秒以下。所以正确姿势是查询慢开EXPLAIN看type、key、rows三个字段。type若出现ALL说明全表扫描key是NULL说明索引完全没走。这些信息和是否用了ORM关系不大纯粹是SQL基本功的问题。4.4 确实该写原生SQL的几个场景我也想说句公道话有些场景你就应该绕开ORM的自动生成机制直接写原生SQL。我归纳出五个高频场景复杂报表统计带多层子查询、窗口函数、临时表关联。用QueryWrapper硬拼条件纯属自虐。大批量更新比如按条件批量更新几十万行。走ORM逐条Loop更新会产生大量事务和网络往返真不如一条原生SQL。复杂动态条件动态拼SQL条件本身需要极高的可读性时写在MyBatis XML里的where、foreach比Java代码里层层构造清晰得多。特殊数据库方言功能MySQL的JSON_EXTRACT、PostgreSQL的ARRAY_AGG等能力ORM封装不完全不如直接写。查询列不固定比如报表模块需要根据用户勾选动态选择查询列这种场景自动映射反而拖后腿。使用MyBatis-Plus时我习惯把简单CRUD和复杂查询分文件管理简单场景用LambdaQueryWrapper复杂场景一律进XML并且用Select注解直接标注原生SQL时记得加上Options控制超时时间。每个团队都该有自己的“原生SQL白名单”而不是一棍子打死。5. 安全防线SQL注入在ORM时代的残余风险5.1 参数绑定的原理决定了95%的安全ORM能有效防住SQL注入原理并不玄乎预编译或参数绑定。当你写WHERE name ?时参数是作为数据传给数据库的数据库不会把它当SQL指令解析。JDBC的PreparedStatement就是干这个的MyBatis的#{}、JPA的?1本质上都走这个路子。我见过很多系统用了ORM之后觉得SQL注入问题自动解决了结果漏出个洞。典型场景是排序字段用户传入sortField开发图省事直接拼进ORDER BY因为MyBatis的#{}无法用在列名或关键字位置只能字符串拼接。这就是典型的残余注入点——ORM防的是值注入但它没法替你判断列名合法性。5.2 MyBatis中的动态SQL安全边界MyBatis里${}和#{}的区别是安全问题的分水岭。#{}生成预编译占位符?安全${}是纯字符串替换危险。我看过不少项目代码把表名、排序列、甚至部分查询条件都用${}拼接完全把参数绑定优势扔了。安全写法其实并不复杂排序字段用白名单映射比如Java里维护一个Map把前端传的createTime映射成真实列名create_time查不到就直接抛参数异常。动态表名如果确实无法避免必须对传入值做正则校验仅允许字母数字下划线。所有模糊查询统一用like #{keyword}不要拼%进去而是传参时拼好。这条边界想清楚了项目的安全底线就比较扎实了。6. 高频问题排查与经验速查6.1 一张表看懂常见ORM问题症状大概率原因快速处理建议列表接口越来越慢SQL数量巨大N1查询检查懒加载触发位置改用批量抓取或DTO转换分页深度靠后时响应极慢深度分页LIMIT offset过大改用游标/键集分页更新数据后查询不到事务未提交或缓存未清先确认事务边界JPA考虑Modifying(clearAutomaticallytrue)并发更新丢失乐观锁缺少Version字段或MyBatis-Plus未配置Version添加版本号字段用乐观锁插件一次保存几百条数据很慢逐条插入产生大量往返批量插入MyBatis-Plus用insertBatchSomeColumn或XMLforeach查询条件没走索引隐式类型转换、条件上函数包装改写SQL或调整参数类型用EXPLAIN验证实体字段变更后数据错乱映射关系漏改数据库迁移脚本与实体字段保持一致集成测试覆盖全字段6.2 排查流程建议当线上查询出问题我建议按这个顺序排查别上来就骂框架先看应用监控统计这个接口到底发了几次SQLP6SPY、Druid Filter都可以。如果次数多优先怀疑N1。如果次数不多但单条耗时高把SQL捞出来去数据库中EXPLAIN看执行计划。如果执行计划没问题再查是不是连接池等待或锁等待。如果数据库本身很快但应用响应慢这时候才需要怀疑结果集映射、网络序列化等ORM层面的开销。6.3 我自己的经验怎么正确练“直接写SQL”的基本功最后分享一点技术之外的看法。网上总有人拿“你会不会手写SQL”和“用不用ORM”对立起来其实这是两码事。越是依赖ORM的团队越要求成员能读懂SQL、会优化SQL、能识别执行计划里的问题。因为你把SQL生成权交给了框架你就必须有审计框架的能力。我给团队的建议是新人入职前几周先让他们手写JDBC完成一个极简的CRUD体会ResultSet映射的繁琐。然后引入MyBatis-Plus让他们感受框架带来的效率提升。等他们掌握了#{}与${}的区别、理解了缓存概念之后再让他们回头用JPA写一个聚合根模型。这套流程走下来绝大多数人不会再纠结“为什么不直接写SQL”而是会问“这里的SQL应该交给ORM生成还是自己掌控”。我个人在实际操作中体会最深的一点是ORM的价值是全流程协同作战不是单点性能竞赛。它让字段变更的传导成本变低让数据库切换时的改造范围变小让新成员编写数据访问代码的安全下限变高。但代价是你必须持续关注SQL日志、执行计划和连接池状态。从这个角度看ORM和手写SQL根本不是替代关系——手写SQL是本建设能力ORM是规模化交付手段两者都要有才算完整的工程素养。如果你还在纠结怎么回答“为什么用ORM”这个问题下次再有人问你的时候可以反问他一句你手上五十张表每个字段变更你都要手工同步到三十条SQL的ResultSet里你确定自己愿意这么长期维护吗技术选型从来不是一道“谁更快”的判断题而是一道“谁更能压住长期成本”的综合题。