你有没有遇到过这种情况一条mysql查询慢得离谱慢查询日志里躺着好几秒你登录数据库一看表上的索引明明都建好了甚至还是复合索引可EXPLAIN一跑key列是NULLtype显示ALL全表扫描。我处理这种“不走索引条件”的问题少说也有上百次了这类问题在性能优化里最磨人——不是没索引而是索引在优化器不用。这篇文章我打算把“MySQL不走索引”这件事彻底讲透。从怎么判断SQL真的没走索引到哪些写法会把索引搞“失明”再到优化器为什么放着索引不用最后给你一套可以直接上手的排查流程。不管你是刚接触数据库的新手还是已经在生产环境里排查过几次慢SQL的开发者这篇文章都能给你一点新东西。尤其是那些平时文档里不写、只有踩过坑才明白的细节我会重点讲。1. 先分清“没走索引”长什么样很多人一看查询慢就急着加索引这是典型的病急乱投医。第一步应该是确认它到底有没有走索引、走到了哪一步、卡在了哪个环节。EXPLAIN是唯一靠谱的手段但前提是你得看得懂它输出的每一列。1.1 慢查询日志才是问题的起点生产环境里你不可能每秒都盯着数据库看慢查询日志就是最好的“监控摄像头”。MySQL默认的long_query_time是10秒也就是超过10秒的SQL才会被记录下来这个阈值对绝大多数业务来说太宽松了建议调到1秒甚至更低。-- 临时调整重启失效 SET GLOBAL long_query_time 1; -- 确认是否生效 SHOW VARIABLES LIKE long_query_time;这里有个小坑这个参数是全局的但已有连接不会立即生效需要重新建立连接才能读到新值。如果你用的是连接池最好在调整后观察一段时间或者直接在配置文件里改好再重启MySQL。另外log_queries_not_using_indexes这个参数很有用开启后凡是没走索引的SQL都会进日志哪怕它只跑了0.1秒。SET GLOBAL log_queries_not_using_indexes ON;从日志里捞出SQL之后别急着改下一步是把这条SQL单独拎出来跑一遍EXPLAIN。1.2 一行EXPLAIN看懂执行计划EXPLAIN这条命令是排查索引问题的第一工具没有之一。用法很简单在查询前面加EXPLAINMySQL会返回一个执行计划。EXPLAIN SELECT * FROM user WHERE mobile 13800138000;输出的结果里有几个关键列我按重要性排个序列名代表含义判断标准type访问类型从好到坏依次是system const eq_ref ref range index ALLkey实际选用的索引名为NULL就是没走索引rows预估扫描行数数字越大越危险Extra附加信息出现Using filesort或Using temporary要特别注意type为ALL是最典型的全表扫描也是我们在排查慢SQL时最不想看到的结果。type为index虽然表示“用了索引”但扫的是整个索引树相当于把索引当成全表来遍历性能好不到哪里去这个稍后细说。key列是最直接的判断如果显示NULL说明优化器根本没选任何索引。1.3 覆盖索引与全表扫描的边界typeindex这个状态容易被误解。它确实走了索引但扫描的是整棵索引树本质上也是全量数据成本可能比全表扫描还高。真正的性能优化目标是type至少到range级别理想状态是ref或const。这里必须提一个概念覆盖索引。如果查询要的字段全部包含在某个索引里MySQL就不需要回表去主键索引里取整行数据这种情况EXPLAIN的Extra列会显示Using index。比如你有一个复合索引(a, b, c)然后执行SELECT a, b, c FROM t WHERE a 1这个查询的所有字段都在索引里不需要回表。加索引时不能光看where条件SELECT的字段也得考虑进去。能设计出覆盖索引性能提升是质的飞跃能从“扫全表”变成“只读索引”。1.4 索引存在但失效的隐蔽情况invisible indexMySQL 8.0开始支持不可见索引。这个特性本意是让你在不删除索引的情况下验证去掉某个索引对性能的影响。但它也有坑如果你把某个索引设为INVISIBLE之后忘了恢复SHOW INDEX还是能看到它可优化器根本不会用它于是表面上索引在实际执行却又没走。排查方法很简单查一下索引的可见性SELECT TABLE_NAME, INDEX_NAME, IS_VISIBLE FROM information_schema.STATISTICS WHERE TABLE_SCHEMA 你的库名;如果看到IS_VISIBLE是NO而你的SQL确实需要这个索引执行下面的语句恢复即可ALTER TABLE user ALTER INDEX idx_mobile VISIBLE;很多同事在8.0版本升级后碰到“索引失效”的诡异问题查了半天索引都在最后发现是invisible flag被人动过或者在创建时不小心加了INVISIBLE关键字。这类问题我不会责怪任何人因为SHOW INDEX里压根不显示这个标记容易被忽略。2. 让索引“失明”的几种写法我见过很多开发者在索引设计上花了很多功夫最后却因为SQL写法的问题让优化器对索引视而不见。这一节是最实战的部分每一条都是我见过多次的典型场景。你会发现大部分失效都不是索引本身的问题而是SQL语句踩了MySQL的规则红线。2.1 索引列上做了运算或函数调用这是最经典的一种失效场景也很容易被新手踩中。只要索引列参与函数运算MySQL就无法利用B树的有序性去定位数据只能老老实实全表扫。-- 失效写法对索引列使用了函数 SELECT * FROM order_test WHERE DATE(create_time) 2025-06-01; -- 生效写法范围查询利用索引有序性 SELECT * FROM order_test WHERE create_time 2025-06-01 AND create_time 2025-06-02;你可能会想结果不是一样的吗但优化器没法把DATE(create_time)自动改写成范围条件。B树的叶子节点按create_time原始值排序DATE()函数处理后的结果完全打乱了原有的顺序。同样的道理在索引列上做算术运算也会失效-- 失效WHERE id 1 10001 -- 生效WHERE id 10000这里有个比较容易忽略的点优化器能自动让你把10001改写成10000吗答案是不能它只会傻傻地认为id1是一个表达式没法直接定位。你在写SQL时应当尽量把运算放在常量那一侧或者在应用层先算好结果。2.2 隐式类型转换一个静默的杀手这个场景极其隐蔽因为SQL能正常跑结果也对就是慢。原因是比较的两边类型不一致MySQL被迫做隐式转换。-- 表字段 mobile 是 varchar(11)条件传的是数字 SELECT * FROM user WHERE mobile 13800138000; -- 正确写法注意类型匹配 SELECT * FROM user WHERE mobile 13800138000;当varchar列和数字比较时MySQL会把varchar转成数字来做比较。这一转换落在索引列上索引就废了。你在EXPLAIN里看到的典型现象是key为NULLtype是ALL但SQL本身没有任何报错。我对这个问题的建议是排查慢SQL时多留意下条件值的类型。如果你用的是MyBatis等ORM框架尤其要检查参数是否被包装成了字符串或者反过来Java代码里传的是Long但SQL参数没配好。类型推断错误会导致你写对了索引优化器却不买账。顺带提一个反例如果索引列是int类型条件写字符串123MySQL会尝试把字符串转成数字再比较这种情况下索引是能用的因为转换发生在列外。但为了可读性和一致性还是建议两边类型严格对齐。2.3 最左前缀复合索引的黄金法则复合索引是我在性能调优中用的最多的索引类型但它也是失效高发的重灾区。最左前缀法则说只有当查询条件用到了复合索引最左侧的列时索引才会生效。-- 假设有复合索引 idx(user_id, status) -- 生效user_id 在最左侧 SELECT * FROM order_test WHERE user_id 10086; -- 生效user_id status完全匹配 SELECT * FROM order_test WHERE user_id 10086 AND status 1; -- 失效跳过了 user_id只使用 status SELECT * FROM order_test WHERE status 1;我经常用“电话簿”这个类比来解释最左前缀电话簿先按国家、再按城市、再按姓氏和名字排序。你知道城市和姓氏但不知道国家就没法快速定位到人。复合索引和这个道理完全一样。还有一个容易混淆的点范围查询之后的条件列会失效。比如索引是(a, b, c)查询a 10 AND b 2b这个条件是没法用到索引的因为a的范围破坏了b的有序性。所以设计复合索引时要把等值条件的列放在前面范围条件的列放在后面。2.4 OR、LIKE、IN等条件的经典陷阱OR条件是个老生常谈的坑。如果OR两边的列都能单独走索引还好但MySQL的优化器有时会为了兼容多个条件而选择全表扫描。-- 假设 user_id 和 status 都有独立索引 -- 这种写法很容易全表扫 SELECT * FROM order_test WHERE user_id 1 OR status 2; -- 拆成两条再 UNION ALL索引就能用上 SELECT * FROM order_test WHERE user_id 1 UNION ALL SELECT * FROM order_test WHERE status 2;不过这不是绝对的。MySQL有index merge优化可以分别用两个索引取交集合并但触发条件比较苛刻取决于表的大小、数据分布和优化器版本。我一般建议能用UNION ALL拆分就优先拆不要赌优化器的merge策略。LIKE查询要看通配符的位置-- 生效最左匹配 SELECT * FROM user WHERE nickname LIKE 张%; -- 失效前导通配符导致索引无法定位 SELECT * FROM user WHERE nickname LIKE %张;IN的情况要分类讨论。IN的值数量较少时走索引没问题但如果你IN了几千个值优化器算算回表成本可能选择全表扫。这时候可以尝试拆分成多个小批次IN或者改用临时表JOIN。NOT IN和!这两个条件也容易被优化器抛弃因为它们意味着“排除少量数据而不是定位少量数据”在数据量大的表上优化器通常会选择全表扫描。如果某个字段的值为0只占1%但你查NOT IN(0)优化器也未必走索引——它的统计精度不够细只能按全局比例估算。2.5 ORDER BY 与 filesort排序引发的拦路劫有些查询过滤条件很快但整体慢问题出在排序上。Extra列里出现Using filesort就说明MySQL在内存里或磁盘上额外做了一次排序这个操作开销不小。-- 假设没有对 create_time 建索引 EXPLAIN SELECT * FROM order_test WHERE user_id 1 ORDER BY create_time DESC;user_id条件走了索引但create_time的排序需要额外处理。原因很简单B树是按索引列排序的你现在要按create_time排但数据实际是按user_idcreate_time的某种顺序存储的除非索引的键设计恰好和排序需求一致。解决思路有两个方向如果排序字段是单列建单列索引如果是复合条件排序的组合比如等值条件排序字段建一个(user_id, create_time)的复合索引这样WHERE条件的等值定位和ORDER BY的排序都能落在同一个索引上。MySQL 8.0开始支持降序索引对于ORDER BY xxx DESC这种频繁出现的SQL可以直接在索引里指定DESC省去排序的额外开销。5.7及以下版本没有这个能力只能靠filesort硬扛。3. 优化器为什么放着索引不用前面讲的都是“因”层面的东西这一节我要聊“果”背后的逻辑。你以为索引失效是SQL写错了但很多时候SQL写得没问题是优化器权衡之后主动抛弃了索引。理解了它的决策逻辑你才能在设计索引时不走弯路。3.1 回表成本让索引“看起来不划算”二级索引也叫辅助索引只存了索引列主键查询需要返回更多字段时MySQL要先在二级索引里找到主键值再回主键索引里取整行数据。这个过程叫“回表”通常对应随机IO。我举个例子你就明白了。一张表有1000万行某个查询条件命中30万行。假如这个条件可以走二级索引MySQL的算账逻辑是这样的通过二级索引定位并读取30万条记录的主键信息再回表30万次每次都涉及随机IO而全表扫描只需要顺序读取表数据文件。30万次随机IO的成本远高于顺序扫描1000万行优化器当然选全表扫描。所以你会遇到一种情况单看结果集只有很小比例但优化器仍然不走索引。原因就是回表成本压过了全表扫描成本。这也是覆盖索引的杀手锏意义。如果查询的字段都在索引里回表次数直接降为0优化器自然愿意走索引。你在设计索引时一定要问自己这张表的查询模式里哪些高频率SQL能做成覆盖索引。3.2 区分度低索引等于废的索引好不好使取决于一个指标区分度也就是数据列的多样性。执行SHOW INDEX FROM可以看到一个Cardinality字段它表示索引中不同值的估算数量。Cardinality相比表行数越小区分度越差。典型例子是性别字段只有男、女、未知三种值如果你建索引WHERE gender male命中了一半行。这种情况下走索引不仅没帮助回表成本还翻倍优化器直接放弃。我在设计联合索引时会刻意把区分度高的列放到前面。比如一个订单表状态字段只有几个值创建时间几乎每行都不同。那么查询经常是WHERE status 0 ORDER BY create_time DESC设计索引时可以考虑(status, create_time)而不是(create_time, status)具体得看查询模式。但核心原则不变让高区分度的列在索引的左边能更快地把搜索范围缩到最小。3.3 统计信息过旧与参数改动导致的误判优化器做成本估算依赖统计信息而统计信息不会实时更新。如果表经历了大量增删改统计数据严重偏离实际优化器就可能做出错误决策。比如它以为某个索引匹配500万行实际上改了以后只剩500行于是弃用了索引。解决办法很直接ANALYZE TABLE order_test;这条命令会重新计算索引的Cardinality更新统计信息。执行完再跑EXPLAIN很可能执行计划就变了。我在例行巡检里都会对频繁变更的大表定期跑ANALYZE TABLE。还有一个隐藏因素optimizer_switch系统变量里有各种优化器开关有些开关会影响索引策略。比如index_merge、condition_pushdown这些选项如果被人改过可能导致某些本该生效的优化策略失效。排查时用SHOW VARIABLES LIKE optimizer_switch看一眼正常情况下保持默认值即可。4. 一次完整的排查实测理论聊了一堆下面我把一次真实排查过程完整重现一遍。你跟着做一遍遇到类似问题就心里有底了。4.1 构造测试表和测试数据为了演示我建一张订单表模拟真实业务场景CREATE TABLE order_test ( id INT PRIMARY KEY AUTO_INCREMENT, user_id INT NOT NULL, order_no VARCHAR(32) NOT NULL, status TINYINT NOT NULL DEFAULT 0, create_time DATETIME NOT NULL, KEY idx_user_status (user_id, status), KEY idx_create_time (create_time) ) ENGINEInnoDB;插入测试数据时注意user_id的数据分布要有区分度比如1000个用户各有若干订单INSERT INTO order_test (user_id, order_no, status, create_time) SELECT FLOOR(RAND() * 1000) 1, CONCAT(ORDER, LPAD(id, 8, 0)), FLOOR(RAND() * 4), NOW() - INTERVAL FLOOR(RAND() * 365) DAY FROM information_schema.COLUMNS LIMIT 50000;这里借用了系统表的行数生成随机测试数据快速又方便不必手写循环。4.2 跑EXPLAIN看失效与生效的完整对比先看一个正常走索引的例子EXPLAIN SELECT * FROM order_test WHERE user_id 123;正常情况下的执行计划里key列显示idx_user_statustype是refrows预估在几百行左右说明优化器顺利使用了复合索引。再看失效的写法EXPLAIN SELECT * FROM order_test WHERE user_id 1 124;执行计划里type变成ALLkey变成NULLrows显示5万行这就是索引列上做运算的典型后果。再看只查status的情况EXPLAIN SELECT * FROM order_test WHERE status 1;因为复合索引最左列是user_id这里是status条件不满足最左前缀法则所以同样无法走idx_user_status。除非status的区分度低优化器更不可能选它通常就是全表扫。再看一个排序场景EXPLAIN SELECT * FROM order_test WHERE user_id 123 ORDER BY create_time DESC;user_id条件走了索引但create_time排序没有可用索引Extra列出现Using filesort这就是查询慢的元凶。改成先查一下索引设计能不能覆盖排序需求。4.3 用optimizer_trace看优化器“内心戏”EXPLAIN只能告诉我们结果想知道优化器具体怎么算账、为什么放弃索引需要用到optimizer_trace。这个方法我日常排查时经常用能直接看到优化器在候选索引之间的成本比较。-- 开启追踪 SET optimizer_trace enabledon, end_markers_in_jsonon; -- 执行你要排查的SQL SELECT * FROM order_test WHERE user_id 1 124; -- 查看追踪结果 SELECT * FROM information_schema.OPTIMIZER_TRACE;输出是一大段JSON重点看access_path部分里面有rows_estimation和cost字段。你会看到优化器对全表扫描算过一笔账如果回表成本太高它会明确选择全表扫描甚至根本不会把某个二级索引列入候选。不要忘了在排查完成后关闭追踪SET optimizer_trace enabledoff;这个工具在生产环境尽量少开因为它会记录所有SQL的优化过程额外开销不小。4.4 解决这类问题的合理检查顺序根据我的经验解决“索引在但不用”的问题顺序比技巧重要。我给自己定了一套检查流程你也可以直接抄走先跑EXPLAIN确认key是否为NULL、type是否ALL、Extra有没有filesort再用information_schema检查索引可见性排除invisible index的坑检查SQL写法索引列有没有函数运算、条件类型是否与列类型匹配检查复合索引顺序是否满足最左前缀法则看统计信息必要时执行ANALYZE TABLE如果是迫不得已的验证可以用FORCE INDEX强制走索引对比一下性能。FORCE INDEX是治标手段我不建议长期使用它纯粹是为了验证“如果走这个索引是否更快”。如果FORCE INDEX确实快但优化器死活不用说明统计信息确实有偏差或者成本模型本身的问题这时候该做的是更新统计信息、调整索引结构而不是用hint硬扛。5. 个人经验与最后的建议排查慢SQL这件事我踩过的坑多了最后形成了一套自己的习惯。想分享给你的是SQL上线前必须先看执行计划不要只在出问题才想起来。我在团队里定的规矩是所有涉及查询的SQL变更测试环境跑一遍EXPLAIN重点看key列有没有掉索引一旦掉了就要解释清楚为什么。索引设计也不要迷信“越多越好”。每个索引都会占用磁盘空间并拖慢INSERT、UPDATE、DELETE的写入性能因为每次写入都要同步维护所有索引。我看到不少项目里一张表建了十来个索引查询是快了写入慢到报警。索引少而精服务的是真实查询模式而不是“可能用得上”的猜测。压测数据量也很关键用100条数据跑EXPLAIN看不出问题索引失效在数据量小的时候根本不会暴露。尽量在测试环境造出和生产一个数量级的数据再验证否则你上线前看到的执行计划和生产环境的完全不是一回事这个教训我是真金白银买来的。最后再分享一个小技巧每次排查完“不走索引”的问题都值得把SQL、对应索引、执行计划的变化记录下来。下次遇到类似场景直接翻之前的笔记往往几分钟就能定位到问题。你会发现90%的索引失效问题逃不开这一篇讲到的几个套路函数运算、隐式转换、复合索引乱序、统计信息不准。把这几关逐一排查效率比盲目试错高太多了。