MySQL查询慢得不行？这几个优化方法你可能没试过，效果还挺不错

说到MySQL数据库,最让人头疼的问题之一就是查询速度慢，页面转圈圈，用户等得不耐烦，自己心里也着急，你可能已经尝试过一些基础的优化方法，比如加个索引什么的，但有时候效果就是不理想，别急，今天咱们就聊几个你可能没太留意，但实际操作起来效果还挺不错的优化技巧，这些方法很多是来自像“阿里云开发者社区”、“Percona官方博客”以及一些资深DBA的实践经验分享。

第一个方法，别让“坏”查询溜进来，用好慢查询日志。

很多时候,我们并不知道到底是哪条SQL语句在拖后腿，系统慢了，感觉是数据库的问题，但具体到哪条SQL，就说不上来了，这时候，慢查询日志就是你的“照妖镜”，这个功能是MySQL自带的，你可以在配置文件里（比如my.cnf）设置一个时间阈值，比如超过2秒的查询就算慢查询，一旦开启，MySQL就会把所有执行时间超过这个阈值的查询语句、执行时间、锁等待时间等信息都详细记录下来。

Percona官方博客就多次强调过分析慢查询日志的重要性,光打开日志还不够，关键是要定期去分析它，你可以用MySQL自带的mysqldumpslow工具，或者一些更强大的第三方工具（比如pt-query-digest）来对慢查询日志进行汇总分析，看看是不是某一条查询出现的频率特别高？是不是某个时间点突然慢查询暴增？通过分析日志，你就能精准地找到需要优化的“元凶”，而不是凭感觉瞎猜，这是优化工作的第一步，也是最关键的一步。

第二个方法，别让索引白建了，检查一下索引的“使用效率”。

你确实给表加了索引,但查询为什么还是慢？可能是因为索引并没有被真正用到，或者用得不高效，这里有个小技巧，就是用EXPLAIN命令来查看MySQL的执行计划，在你要优化的SQL语句前面加上EXPLAIN，然后执行，MySQL就会告诉你它打算怎么执行这条查询。

这里要特别关注几个地方,一个是type列，它表示连接类型，如果这里显示的是ALL，那就意味着全表扫描，这是最糟糕的情况，说明索引根本没起作用，理想情况是达到ref或range这个级别，另一个是key列，它显示的是MySQL实际决定使用的索引，如果这一列是NULL，那也说明没用到索引，有时候你会发现，你建了索引A，但MySQL却选择了索引B，甚至不用索引，这可能是因为索引的“区分度”不够，你在一个只有“男”、“女”两种值的性别字段上建索引，因为重复值太多，数据库觉得走索引还不如全表扫描快，建索引要尽量建在区分度高的字段上。

第三个方法，别让数据库“算”得太多，减少不必要的计算和请求。

有些慢查询,问题不出在数据本身上，而是出在SQL语句的写法上，在WHERE子句中对字段进行函数操作，就像WHERE YEAR(create_time) = 2023，这样即使create_time字段有索引，索引也会失效，正确的写法应该是WHERE create_time >= '2023-01-01' AND create_time < '2024-01-01'。

还有,尽量避免使用SELECT *，阿里云的开发者社区文章里就经常提到这一点。SELECT *会把所有字段都捞出来，包括那些你根本用不上的大字段（比如TEXT类型），这会增加网络传输和数据解析的开销，只取你需要的字段，能有效减轻数据库的负担，审视一下你的查询是否返回了过多的数据，如果用户只需要看前10条记录，你却一下子查出来一万条，这显然是一种浪费，合理地使用LIMIT来限制返回的行数，也是一个立竿见影的优化手段。

第四个方法，当单表太大时，考虑“分而治之”。

当一张表的数据量增长到几千万甚至上亿条的时候,即使有再好的索引，查询性能也可能会下降，因为索引树会变得非常深，一次查询需要读取的磁盘页也更多，这时候，就需要考虑一些“架构层面”的优化了，也就是我们常说的分库分表。

分表有两种常见的思路,一种是水平分表，比如按时间范围，把2022年的数据放一张表，2023年的放另一张表，或者按某个字段的哈希值取模，把数据均匀分布到多张表里，另一种是垂直分表，就是把一些不常用的、或者长度很长的字段（比如商品详情）从主表里拆分出去，单独成表，这样可以减少主表的大小，让常用查询更快，这个方法实施起来相对复杂，需要业务代码的配合，但对于处理超大规模数据来说是必经之路，很多大型互联网公司的技术分享中都详细讨论过他们的分库分表实践。

第五个方法，有时候问题不在SQL本身，而在“环境”。

查询慢,不一定全是SQL语句的锅，数据库所在的服务器状态也会有很大影响，服务器的内存不足，导致频繁的磁盘交换（SWAP），磁盘IO就成了瓶颈，或者，MySQL的缓冲池（innodb_buffer_pool_size）设置得太小，无法缓存足够的热点数据，同样会导致查询需要频繁读写磁盘，速度自然就慢下来了。

定期检查服务器的CPU、内存、磁盘IO使用情况是很有必要的，根据服务器的硬件资源，合理地调整MySQL的配置参数，比如适当调大缓冲池的大小，往往能带来全局的性能提升，而不用修改任何一行SQL代码，这就像给汽车换了一条更宽阔的马路，即使车本身没变，跑起来也顺畅多了。

优化MySQL查询是一个需要耐心和细致观察的过程,从开启慢查询日志定位问题，到用EXPLAIN分析索引使用情况，再到优化SQL写法，最后到架构和系统层面的调整，每一步都可能带来意想不到的效果，希望这几个方法能给你提供一些新的思路。