上周有个朋友跟我吐槽，说他们公司的MySQL数据库慢得像蜗牛爬，一个简单的报表查询要跑半小时，老板天天在群里@他，问是不是服务器该换了。我听完就笑了，服务器多半没毛病，有毛病的是SQL语句和索引设计。干这行十几年，我见过太多人一遇到数据库性能问题就想着加硬件、换机器，其实90%的场景下，你根本不需要花那个冤枉钱。今天我就把压箱底的三招掏出来，全是实操中验证过的，不用搞什么高大上的理论，上手就能见效。
第一招，也是最容易被忽视的一招：别让SELECT 祸害你的数据库。很多人写SQL的时候图省事，上来就是SELECT ，心想反正数据都在那，多查几个字段又不费电。但你仔细想想，一张表可能有几十个字段，而你真正需要的可能就三五个。MySQL每次执行查询，都要先把所有字段的数据从磁盘读到内存，再通过网络传给你的应用。字段越多，IO开销越大，网络带宽占用越高。我一个客户，把业务表里的SELECT * 全部改成了只查需要的字段，再配合覆盖索引，查询耗时直接从3秒降到了0.1秒。这不是魔法，是常识。你想想，你去超市买菜，明明只买一颗白菜，结果推着购物车把整个超市逛了一遍，能不快吗？
第二招，索引不是越多越好，但该加的时候千万别手软。我见过两种极端：一种人一张表建了十几个索引，觉得这样查询肯定快；另一种人一张表一个索引都没有，美其名曰“读写均衡”。这两种做法都挺坑的。索引确实能加速查询，但每多一个索引，写入数据的时候就要多维护一棵B+树，插入、更新、删除的性能都会下降。所以索引的关键在于精准，而不是数量。具体怎么做？先找出你查询中最常用的WHERE条件字段、JOIN关联字段和ORDER BY排序字段，这些是建索引的首要目标。然后注意一个细节：联合索引的字段顺序很重要，选择性高的字段放前面。什么叫选择性高？比如性别字段只有男女两种值，选择性就很低；而手机号字段几乎每条记录都不同，选择性就很高。把手机号放在联合索引的最左边，能最大程度缩小查询范围。别问我为什么，你试试就知道了，效果立竿见影。
第三招，也是很多人容易忽略的：慢查询日志是你的免费体检报告。MySQL自带的慢查询日志功能，很多人从来没用过，甚至不知道它的存在。这玩意儿就像一个监控摄像头，能记录下所有执行时间超过你设定阈值的SQL语句。你只需要在配置文件中打开slowquerylog开关，把longquerytime设成1秒或者0.5秒，然后跑一两天业务，去翻翻慢查询日志文件，那些拖后腿的SQL语句全都无所遁形。我见过最夸张的一个案例，一条SQL跑了200多秒，原因是表连接时没加索引，导致全表扫描加嵌套循环，数据量一大就直接崩了。找到问题后，加了个索引，200秒变0.02秒。你说这种问题，你要是不查日志，靠猜能猜出来吗？所以别偷懒，养成定期分析慢查询日志的习惯，比什么优化工具都管用。
说完这三招，你可能觉得不过瘾，那我再送你一个进阶技巧：理解MySQL的执行计划。EXPLAIN命令能告诉你MySQL是怎么执行你的SQL的——是用了全表扫描还是索引查找，扫描了多少行，用了哪个索引，有没有用到临时表或文件排序。这些信息就像一张地图，告诉你当前的查询路线是不是最优的。比如你看到type字段显示的是ALL，那就说明是全表扫描，赶紧加索引；看到Extra字段里有Using filesort，说明排序没走索引，得优化ORDER BY的索引设计。我每次调优SQL，第一步就是跑EXPLAIN，看一眼执行计划，基本就能判断问题出在哪。这招用熟了，你甚至不用看慢查询日志，扫一眼EXPLAIN的结果就知道这条SQL会不会拖垮数据库。
还有一点很多人不知道：MySQL的查询缓存其实没那么好用。早期版本的MySQL有查询缓存功能，很多人觉得开了就能自动加速，但事实上在高并发写入的场景下，查询缓存反而会成为性能瓶颈。因为每次表数据有更新，MySQL就得把该表相关的所有查询缓存全部清空，缓存命中率低不说，还额外增加了锁竞争的开销。MySQL 8.0已经直接移除了这个功能，说明官方也意识到它不靠谱。所以别指望查询缓存救你，老老实实从SQL语句和索引设计上找突破口。
我想说，数据库优化没那么玄乎，它就跟你收拾房间一个道理：把不用的东西扔掉（去掉不必要的字段和查询），把常用的东西放在顺手的地方（建好索引），定期检查哪里乱套了（分析慢查询日志）。你照着这三招去干，别说提升30%的性能，提升300%都不是问题。我那个朋友按我说的调整之后，报表查询从半小时缩到了不到1秒，老板再也不在群里@他了，反而给他发了奖金。所以别犹豫了，今天下班前就去翻翻你的慢查询日志，看看哪些SQL在偷懒，该加索引的加索引，该改SQL的改SQL，说不定明天你的数据库就飞起来了。
