刚接手一个电商项目时，数据库慢得让人抓狂。订单查询要等十几秒，报表统计动不动就超时，用户投诉电话打爆了客服。翻看代码，发现SQL语句写得随意——满天飞，关联查询全靠子查询嵌套，索引用得稀里糊涂。这其实不是个例，很多开发团队把SQL当成“能跑就行”的活儿，结果系统一上线就原形毕露。数据库优化说白了就是跟数据量赛跑，数据少时啥都无所谓，数据一上来，那些偷懒的写法全得还债。
先说说最基础的索引问题。很多人的误区是“建了索引就万事大吉”，实际上索引是把双刃剑。有一次排查慢查询，发现一张订单表上建了十几个索引，单次插入却要等好几秒。为什么？因为每次写数据，数据库要同时维护所有索引，写操作自然变慢。更常见的是索引没被用到——比如在 条件里对索引列用了函数，像 ，索引直接失效。正确的做法是改成 。还有联合索引的字段顺序，最常用的条件放最前面，这个原则很多人知道，但真写代码时就忘了。比如查询用户订单， 和 的效率天差地别，因为 的区分度更高。
再说说查询语句本身的设计。很多人写SQL喜欢“一步到位”，一个查询塞进十几张表关联，结果执行计划一看，全是全表扫描。有个真实案例：一张商品表关联评论表、订单表、库存表，统计每个商品的销量和评价数，写成一个左连接再加子查询，跑了三分钟。后来拆成两个步骤——先查商品基础数据，再用 子查询分别统计销量和评价，在应用层组装，总耗时降到 0.5 秒。这不是说关联查询不能用，而是要看数据量。小表关联大表，或者大表关联大表，执行计划经常走偏。这时候用 看一下，如果 数突然暴涨，或者 列出现 “ALL”，就得考虑改写了。
还有一种情况更隐蔽：隐式类型转换。比如 字段是 类型，写查询时用了 ，数据库会把所有 转成数字再比较，索引直接失效。类似的问题还包括字符集不一致——两个表关联用的字段，一个是 ，也会导致索引失效。这些细节看着不起眼，但积累起来，慢查询就会成为常态。我见过最离谱的案例，一个 语句因为没加索引，锁住了整张表，结果线上业务停了半小时。所以每次写SQL前，先问自己：字段类型对吗？会不会触发转换？关联条件能走索引吗？
分页查询也是重灾区。传统的 写法，offset 越大越慢，因为数据库得先扫描前面的所有行。比如查第 100 页，offset 是 990，实际上它先读了 1000 行，再丢掉前 990 行。数据量达到百万级时，这种写法会让你等到怀疑人生。解决方案有两个：一是用 代替 offset，二是用子查询先定位主键。比如 ，走索引扫描，性能提升几十倍。还有一种取巧办法，就是限制用户只能翻到前几页，超过一定页码直接提示“数据太多，请缩小搜索范围”。虽然粗暴，但确实有效，很多大厂都在用。
数据量再大一些，就得考虑分库分表或缓存。但很多人一上来就想上分布式，其实大多数场景下，优化SQL本身就能解决 90% 的问题。比如把 改成只取需要的字段，减少网络传输和内存占用；用 代替 ，特别是子查询结果集小的时候；避免在 条件里使用 ，拆成 往往更快。还有 和 ，能走索引就尽量走，不能走时考虑用覆盖索引减少回表次数。这些调整听起来琐碎，但每个改动都能省下几毫秒到几秒，积少成多，系统吞吐量就上去了。
聊点心态问题。很多开发觉得SQL优化是 DBA 的事，自己只管写业务逻辑。这话放到十多年前可能还行，现在数据量动不动就上亿，业务逻辑再复杂，DBA 根本忙不过来。最理想的状态是，开发写完SQL就顺手用 检查一遍，看到 “Using filesort” 或 “Using temporary” 就警醒一下。而且现在很多数据库工具都能直接显示慢查询日志，每天花十分钟扫一眼，哪些语句该优化心里就有数了。说白了，SQL优化不是高深技术，更像是一种习惯——每次写查询都多想一步数据的分布，多看一眼执行计划。时间长了，写出来的代码自然又快又稳。系统快不快，不光是架构师的事，每一行SQL背后，都藏着对数据的态度。
