上周帮一个朋友调数据库，他们公司有个报表查询，跑一次要40秒。老板每次开会前刷新页面，都能喝掉半杯咖啡。我翻了翻他们的表结构，发现三张表都没建索引，还有一个字段存了 JSON 数据，且用了好几层子查询嵌套。改完以后，查询时间从 40 秒降到 1.2 秒。朋友说，老板那杯咖啡还没喝完，报表就出来了。
其实很多团队都踩过类似的坑。数据库查询慢，十有八九不是硬件不行，而是表设计没想清楚。再多服务器，也挡不住一张表里塞了上亿行数据、连索引都没有的情况。今天我就聊聊三个最实用的优化策略，都是我在实际项目中反复验证过的。不扯理论，只讲能直接拿来用的方法。
先说第一个策略：合理的索引设计，是查询加速的第一道开关。
很多人对索引的理解就是“给字段加个索引就快了”，但怎么加、加在哪些字段上，差别巨大。我见过最离谱的例子，有个表上建了 12 个索引，却仍然慢。为什么？因为索引太多，插入和更新时，数据库要维护每个索引，反而拖慢了整体性能。正确的做法是，分析查询模式，只给那些频繁出现在 WHERE 条件、JOIN 关联字段、ORDER BY 排序字段上的列建立索引。而且要注意索引的顺序，例如你经常查询“状态+创建时间”，就建一个复合索引（状态, 创建时间），而不是分别建两个单列索引。复合索引能直接命中数据，避免回表查询，性能提升可达 10 倍以上。
但索引也不是万能的。有时候加了索引，查询还是慢，问题可能出在第二个策略：避免不必要的数据扫描，学会“剪枝”。
什么叫剪枝？就是尽量让数据库少干活。最常见的坑是全表扫描，尤其是大表，动不动几百万行。你要做的第一件事是检查查询条件，看有没有办法缩小扫描范围。比如查询“最近一周的订单”，如果表里有上亿条历史数据，就一定要在 WHERE 里加时间范围，哪怕只扫最近一个月的数据，也能省下 90% 的扫描量。还有一个容易被忽略的点：避免使用 SELECT 。很多人习惯写 “”，结果返回大量不需要的字段，IO 开销直接拉满。改成只查询必需的字段，性能能提升 30% 到 50%。另外，子查询和函数运算也是性能杀手。比如在 WHERE 里用 DATE() 处理时间字段，会导致索引失效，改成直接用 >= 和 < 比较，数据库就能走索引。
第三个策略：表结构设计要“瘦身”，通过适度冗余提升性能。
很多开发者喜欢把表设计得特别“规范”，恨不得每个字段都拆成一张表。但在实际线上业务中，过度范式化反而会拖慢查询。比如用户表和订单表，每次查询订单都要关联用户表拿用户名，JOIN 在大数据量下特别慢。这时适度冗余就很重要——在订单表里直接存一个用户名字段，虽然违背了第三范式，但能省掉一次 JOIN，查询速度翻倍。还有一个常见优化是字段类型的精简。比如存储 IP 地址，很多人用 VARCHAR(15)，其实用 INT UNSIGNED 存，只占 4 字节，比字符串省了约 70% 的空间，查询时用 INETATON 和 INETNTOA 转换即可。字段越短，内存能装下更多行，缓存命中率就越高。
说到缓存命中率，不得不提一个细节：表里用不上的历史数据该归档就归档。很多公司的订单表、日志表多年不清，数据量膨胀到几十亿行。实际上业务只关心最近半年的数据，这时可以把半年前的数据迁移到归档表或冷存储，主表只保留热数据。这样主表体积变小，索引深度也浅，查询速度自然提升。我曾帮一个电商团队把日志表按月分表，每个表只保留两个月的数据，查询时间从 10 秒降到 0.5 秒以内。
优化数据库表，核心一句话：让数据库少干活，让数据离 CPU 更近。索引帮它快速定位，剪枝帮它减少扫描，瘦身帮它压缩体积。这三件事做好了，90% 的性能问题都能解决。
你可能会问，这些策略听起来简单，为什么还有团队踩坑？原因无非两个：一是上线前没人认真做压测和慢查询分析，二是业务增长后没人定期做表结构 Review。数据库优化不是一次性工作，而是随着数据增长和查询模式变化，需要持续迭代的过程。
说个真实案例。去年有个客户，核心查询跑了 15 秒，使用了三层子查询，表里还有大量重复数据。我们做了三件事：第一，把子查询改成 JOIN，减少临时表生成；第二，给关联字段建了复合索引；第三，去除重复数据，表体积缩小了 40%。最终查询时间降到 0.8 秒。老板后来发消息说，技术团队终于不用背锅了。
回到开头的朋友，他现在每周都会跑一次慢查询日志，主动优化那些“还能再快一点”的 SQL。数据库优化这件事没有终点，只有更好。你什么时候开始动手，你的用户就能少等几秒钟。而那些省下来的时间，就是产品竞争力的直接体现。
