上周三晚上十一点，我正盯着屏幕上那个转了快两分钟的加载圈，手里的咖啡已经凉透了。那个后台报表页面，就查三天数据，愣是卡得像个年迈的蜗牛。我下意识看了眼数据库监控，CPU飙到90%，慢查询日志里堆满了同一个SQL的影子。那一刻我意识到，问题不在网络，不在服务器，就在那条写了半天的查询语句上。
这事搁谁身上都窝火。你辛辛苦苦把业务逻辑理清楚了，索引也加了，可查询还是慢。慢在哪？慢在数据库不知道你想干什么，或者更准确地说，它知道你想干什么，但选了一条最笨的路去干。就像你明明有导航，偏要走老城区那条堵车的路，因为导航默认你更熟悉那条路。数据库的查询优化器也是这么个脾气，它根据统计信息猜，猜错了，就全表扫描给你看。
第一个技巧其实最朴素：别查你不需要的列。我见过太多人写SELECT ，然后代码里只用其中两三个字段。你以为无所谓，数据库可不这么想。它得把每一行的所有列都从磁盘读出来，传到内存，再传给应用。一张表二十个字段，你只要三个，那剩下十七个字段全是在做无用功。更麻烦的是，如果这张表有TEXT或者BLOB类型的列，那一次查询可能要读好几个数据页，慢得离谱。改法很简单，把星号换成你真正要的列名。就这么一个动作，有些查询能快上三四倍，真不是夸张。
第二个技巧，给WHERE和JOIN的字段配上合适的索引。但这里有个坑，很多人以为索引越多越好，结果一张表建了十几个索引，写入变慢了，查询也没快多少。索引不是装饰品，它是给数据库指路的。你建了索引，优化器才有机会走索引扫描，而不是全表扫描。但索引建得对不对，得看你查询的模式。比如你经常按时间范围查订单，那(orderdate)这个单列索引就够用了。如果你经常按用户ID和时间一起查，那(userid, orderdate)这种联合索引更合适。这里有个小细节，联合索引的顺序很重要，最常用的等值条件放前面，范围条件放后面。你要是搞反了，索引照样失效，数据库还是会傻乎乎地全表扫。
第三个技巧，也是我踩过最多坑的地方——别让函数和隐式转换毁了你的索引。你写WHERE DATE(createtime) = '2025-01-01'，看起来挺正常，但这一下，索引就废了。因为数据库得先对每一行的createtime做DATE函数运算，才能跟右边的值比较，函数一上场，索引就帮不上忙了。正确写法是WHERE createtime >= '2025-01-01' AND createtime < '2025-01-02'。还有隐式转换，字段是字符串类型，你传了个数字进去，数据库偷偷帮你转类型，索引又废了。这种事特别隐蔽，查出来的结果没错，但就是慢，你还不知道咋回事。
说个我自己的真实案例。去年给一个电商项目做性能排查，有个订单列表接口，响应时间稳定在4秒多。我看了一眼SQL，SELECT FROM orders WHERE userid = 123 AND status = 1 ORDER BY createtime DESC LIMIT 20。表里一千多万行数据，userid上有索引，但status和createtime没在同一个索引里。优化器选了userid的索引，然后回表查status，再排序，再取前20条。问题是这个用户下单特别多，光这个用户就有一百多万条订单记录，回表回得那叫一个酸爽。后来我改成联合索引(userid, status, createtime)，查询时间直接从4秒多掉到80毫秒。五十倍的差距，就改了一个索引。
这里我还得提醒一句，优化SQL不是一锤子买卖。你今天优化好了，明天数据量涨了，查询模式变了，可能又慢了。所以得养成看执行计划的习惯。MySQL里EXPLAIN一下，PostgreSQL里EXPLAIN ANALYZE一下，看看有没有全表扫描，有没有filesort，有没有临时表。这些关键词一出现，基本就是性能杀手。把这些处理掉，查询速度自然就上来了。
还有个容易被忽略的点，分页查询。LIMIT 100, 20这种写法，数据库得先把前面十万行都扫一遍，然后丢掉，只给你二十行。数据量小的时候感觉不到，数据量一上来，这页翻得跟老牛拉破车似的。优化方法也简单，用WHERE id > 上次查询的最大ID来替代OFFSET，或者用子查询先定位到起始位置，再取后面的数据。这种写法看起来绕，但实际执行效率高得多，因为数据库只需要走索引，不需要把中间那些没用的行都读一遍。
回到开头那个让我咖啡凉透的晚上。我花了大概二十分钟，把那条SQL改了改：把SELECT *换成了具体字段，把WHERE条件里的函数去掉，加了一个联合索引，又把排序字段放进了索引里。刷新页面，加载圈转了一秒都不到，数据就出来了。那一刻的感受，说实话，比喝了口热咖啡还舒坦。
数据库查询优化这事儿，说难也难，说简单也简单。难的是你得理解数据库是怎么工作的，简单的是翻来覆去就那么几个套路：少取数据、走对索引、别让优化器犯迷糊。你把这三点记牢了，再遇见慢查询，心里就有底了。下次再有人说数据库慢，你可以拍拍他肩膀，说：别急，我教你三招，保准让它飞起来。
