公司新来的实习生小李最近一脸困惑地问我：‘哥，咱们这系统里到处都是ref="/tag/143/" style="color:#874873;font-weight:bold;">SQL语句，是不是该用个ORM啊？大家都说写原生SQL容易出事。’我笑了笑，递了杯茶过去，说：‘你先告诉我，你觉得做饭非得用料理机吗？’
ORM不是万能钥匙
现在不少项目一上来就上Django ORM、Hibernate、MyBatis这些工具，觉得不走ORM就不够现代化。但实际情况是，有些场景下ORM反而成了累赘。比如你要查一张报表，涉及五张表联查，还要按时间分组、算同比环比，这时候用ORM写出来代码又长又慢，还不好调试。不如直接写一条清晰的SQL来得痛快。
就像修车师傅不会每次换轮胎都从造扳手开始，我们也不必每个查询都绕一圈ORM。如果目标明确，动作简单，直奔主题更高效。
什么时候适合直接写SQL
做服务器维护这些年，遇到太多因过度依赖ORM导致性能崩盘的例子。有次一个订单导出功能卡到40秒才出结果，一看日志，ORM生成了七层嵌套子查询，还对大表做了多次全扫描。改写成一条带索引优化的SQL后，响应压到了800毫秒以内。
复杂统计、批量更新、跨库操作、历史数据迁移——这类任务交给原生SQL更靠谱。你能精准控制执行计划，也能配合数据库特性做优化，比如利用窗口函数、CTE或者特定数据库的并行处理能力。
也别忘了安全和可维护性
当然，直接写SQL不等于可以乱来。参数拼接必须用预处理，别图省事把用户输入直接塞进字符串。下面这种写法要坚决避免：
SELECT * FROM users WHERE name = ' " + userName + " '正确的做法是使用占位符绑定参数：
SELECT * FROM users WHERE name = ?或者在存储过程里封装逻辑，既保留SQL灵活性，又防止注入风险。另外，把常用SQL抽成文件或常量管理，加好注释，团队协作时也不会掉坑。
工具是手段，不是目的
上周帮运营导一次促销数据，需求临时变了三次，字段增减频繁。要是走ORM模型，光改类定义就得来回折腾。我直接在脚本里调SQL，五分钟调整完发给他们，省得反复编译部署。
说到底，用不用ORM不该是个信仰问题。系统压力小、开发快，ORM帮你省时间；性能要求高、查询复杂，SQL让你掌握主动权。关键是看活儿怎么干最顺手，而不是硬套某种模式。
后来我对小李说：‘工具箱里不能只有一把螺丝刀。该拧的用扳手，该敲的拿锤子。写代码也一样，ORM能用，但别忘了SQL才是和数据库真正对话的语言。’