MySQL索引出问题了，数据查询慢得让人抓狂，教你怎么快速修复和避免再次崩溃

朋友，你是不是也遇到过这种情况？明明网站或者应用之前跑得好好的，突然之间，某个页面加载慢得像蜗牛，数据库服务器CPU直接飙到100%，整个系统感觉随时要挂掉，你急得满头大汗，查了半天代码，感觉逻辑也没问题啊？这时候，十有八九是你的MySQL索引“掉链子”了，索引就像是数据库这本书的目录，目录坏了，你就得从头到尾一页一页地翻,那能不慢吗？

今天咱们就抛开那些让人头疼的专业术语，用大白话聊聊怎么快速把这个问题解决掉,以及以后怎么避免它再来找麻烦。

第一部分：紧急救援！快速定位并修复当前的索引问题

当问题突然发生时，别慌，按下面几步走,大概率能快速稳住局面。

1. 找到那个“罪魁祸首”的慢查询 光感觉慢不行，得用证据说话，MySQL自己就带了个“记录本”，专门记下那些执行得特别慢的语句，你需要先确认这个功能开了没有，连接到你的数据库，执行这个命令看看：（来源：MySQL官方文档关于慢查询日志的说明） SHOW VARIABLES LIKE 'slow_query_log'; 如果结果是OFF，那就赶紧打开它（临时生效，重启会失效）： SET GLOBAL slow_query_log = 'ON'; 然后设置一下，超过多少秒的查询才算“慢”（比如设为1秒）： SET GLOBAL long_query_time = 1; 这样，MySQL就会开始把执行时间超过1秒的查询都记录到日志文件里，你去找到这个日志文件（可以用SHOW VARIABLES LIKE 'slow_query_log_file';查看位置），里面就躺着拖垮你数据库的“真凶”。

2. 使用“诊断神器”EXPLAIN 找到了慢查询语句，比如是SELECT * FROM users WHERE name LIKE '%张%' ORDER BY create_time DESC;，下一步就是看看它为什么慢，在查询语句前面加上EXPLAIN，像这样：（来源：MySQL官方文档对EXPLAIN的阐述） EXPLAIN SELECT * FROM users WHERE name LIKE '%张%' ORDER BY create_time DESC; 执行后，你会看到一张表，别被那些列名吓到,你主要关注两列：

   • type列：这代表了查询的类型，如果这里显示的是ALL，恭喜你，中奖了！这就是所谓的“全表扫描”，意味着MySQL在翻整本书，而不是用目录,这是我们重点要消灭的情况。
   • key列：这显示MySQL实际使用了哪个索引，如果这一列是NULL，说明它根本没用到任何索引,或者它可能用了一个效率极低的索引。

3. 对症下药，创建或修改索引 通过EXPLAIN诊断后，问题就很清楚了：要么是没索引可用,要么是现有的索引没用上或者不合适。

   

   • 没索引：如果WHERE条件里用到的字段（比如上面的name字段）没有索引，那就赶紧给它创建一个： CREATE INDEX idx_name ON users(name);
   • 索引不合适：你的查询条件涉及多个字段，或者有排序（ORDER BY），单字段索引可能不够用，比如上面那个查询，既要按name模糊查，又要按create_time排序，这时候，创建一个“联合索引”可能效果更好：（来源：数据库性能优化实践中关于联合索引的常见用法） CREATE INDEX idx_name_createtime ON users(name, create_time); 注意，联合索引的顺序很重要,原则是把最常用于查询条件的列放在前面。

   经过以上三步，紧急创建或调整索引后，那个慢得抓狂的查询速度会有立竿见影的提升,数据库的压力也会瞬间降下来。

第二部分：长治久安！如何避免索引问题再次发生

救火成功固然可喜，但总不能天天救火,我们要从根本上避免问题。

1. 养成习惯：新表上线，索引先行 在设计数据库表的时候，就要根据业务查询的需求，把索引一并设计好，不要等业务跑起来了，数据量大了，才想起来建索引，那时候不仅问题已经发生,而且在大表上创建索引本身就是一个非常耗时且可能影响性能的操作。

2. 定期“体检”：监控慢查询日志 不要把慢查询日志当成一个只在出问题时才用的工具，应该把它常态化开启（在生产环境，long_query_time可以设得稍微宽松点，比如2-3秒），并定期去查看和分析，这样你就能在问题变得严重之前，提前发现哪些查询正在“变慢”,从而主动优化。

3. 理解索引的“脾气”：避免索引失效的坑 索引不是万能的，有些写法会导致索引失效，让你的精心优化白费，常见的坑有：（来源：常见的SQL编程规范与最佳实践）

   • 左模糊匹配：就像我们例子里的LIKE '%张%'，尤其是前面加了，索引基本就失效了，应尽量避免，如果业务允许，尝试用LIKE '张%'。
   • 对索引列进行运算或函数操作：WHERE YEAR(create_time) = 2023，这个YEAR()函数会让create_time上的索引失效，应该写成WHERE create_time BETWEEN '2023-01-01' AND '2023-12-31'。
   • 使用不等于条件： 或 <> 往往会导致全表扫描。
   • 类型不一致：如果索引列是字符串类型，查询条件却用了数字，比如WHERE phone = 13800138000（phone是varchar类型）,索引也可能失效。

4. 不是索引越多越好 索引虽然能加速查询，但也是有代价的，每次你对数据进行增、删、改操作时，数据库不仅要动数据，还要去更新对应的索引，相当于一份活变两份活，所以索引越多，写操作的成本就越高，需要在高读低写的表上合理创建索引，并定期清理那些很少被用到的“僵尸索引”。

处理MySQL索引问题，紧急情况下要冷静，用慢查询日志和EXPLAIN工具快速定位并解决；长远来看，要把索引的设计和监控作为日常运维的一部分，了解索引的习性，避免踩坑,这样你的数据库才能跑得既快又稳。