前两天和一个做后端的朋友吃饭，他吐槽说刚接手一个老项目，数据库慢得像乌龟爬，页面加载动不动就十几秒，用户投诉电话都快打爆了。我问他怎么不查查SQL，他苦笑说查了，但就是不知道从哪下手。这事儿我太熟了，干了十几年媒体，采访过不少技术团队，几乎每个项目到了后期，数据库优化都是绕不开的坎。说白了，SQL写得好不好，直接决定了系统是飞起来还是趴下去。
很多人以为数据库优化就是加索引，这想法太天真了。我见过一个案例，某电商平台订单查询页，开发团队一次性加了六个索引，结果查询反而更慢了。为什么？索引不是越多越好，每个索引都会增加写入成本，而且查询优化器可能会选错索引。真正的高手做优化，第一步永远是搞清楚业务场景：是读多写少，还是写多读少？是实时查询，还是批量处理？这些搞不清楚，后面的优化全是瞎忙活。我认识一个 DBA，他接手新系统的第一件事不是看代码，而是和业务方聊三天，弄清每个查询背后要解决什么问题。
说到具体优化，最基础也最容易被忽视的，就是学会看执行计划。很多开发同学写 SQL 全靠直觉，觉得这么写应该快，结果跑起来就崩。我见过一个查询，明明只需要查十条数据，结果扫了全表一百万行。打开执行计划后发现索引失效，原因特别简单：WHERE 条件里对索引字段用了函数。比如 ，这种写法索引根本用不上，改成 。就这么一个改动，查询时间从八秒降到零点几秒。差别大不大？
另一个常见坑是分页查询。很多系统的列表页直接写 ，这种写法会让数据库先扫十万行，再丢掉前面的九万九千八百行，只为拿二十条。我采访过一家在线教育公司，他们的课程列表页就是这样写的，用户翻到后面几页，页面直接卡死。后来改成基于游标的分页，用 ，效率提升了几十倍。改动成本极低，却立竿见影。很多问题其实不是技术多高深，而是太习惯写那种“能跑就行”的代码。
说到连接查询，这里面的门道更多。很多人写多表关联，习惯用子查询，比如 。这种写法在大数据量下就是灾难，因为子查询会被反复执行。我一个朋友的公司做报表系统，一个查询跑了四十分钟还没出结果，改成 后秒出。但 也不是随便写的，小表驱动大表是铁律， 和 的选择也要根据数据特性来。最离谱的是我看到有人在 条件里用 ，那简直是给数据库上刑。
还有一个被严重低估的优化点是字段设计。很多开发图省事，所有字段都用 ，连日期、数字都用字符串存。这导致两个问题：一是存储空间浪费，二是查询效率低。数字比较比字符串快得多，日期类型也有专门的索引优化。我见过一个系统，订单表的订单号字段用 存，结果查询时因为要比较字符串，比用数字类型慢了五倍。更别说那些用 存短文本的，直接导致全表扫描。数据库设计时多想一步，后面能省多少事。
事务和锁的问题也值得说。高并发场景下，不恰当的事务设计会让系统直接瘫痪。我采访过一个做秒杀系统的团队，他们最初把整个秒杀流程放在一个事务里，结果用户一多，数据库锁冲突严重，吞吐量上不去。后来改成两步：先减库存，再生成订单，减库存用乐观锁，生成订单用独立事务。这个改动让系统扛住了百万级并发。很多人写事务，恨不得把所有操作都包进去，觉得这样才安全，实际上过度使用事务反而降低性能，还容易导致死锁。
想说，数据库优化不是一次性的工作，而是一个持续的过程。系统上线后，数据量在增长，业务逻辑在变化，昨天的优化方案今天可能就失效了。我认识一个技术负责人，他要求团队每个季度做一次慢查询分析，把执行时间超过 100 毫秒的 SQL 全部拎出来 review。这个习惯让他们的系统运行了三年没有出现大问题。优化没有银弹，没有万能公式，唯一的捷径就是养成好习惯：写 SQL 前想清楚业务逻辑，写完看执行计划，上线后定期复盘。做到这些，你的数据库就不会拖后腿。
