MySQL USE INDEX 怎样诊断优化器的索引选择

MySQL 选择了一个你不希望使用的索引时，先不要直接把 USE INDEX 当成永久修复。更稳妥的做法是先看原始 EXPLAIN，确认优化器有哪些候选、实际用了哪个索引，以及它估算要读多少行；然后用 USE INDEX 限定候选集合，做一次可解释的对照。

官方文档：https://dev.mysql.com/doc/refman/8.4/en/index-hints.html

先用 EXPLAIN 找到优化器的选择分歧

MySQL 的优化器会根据谓词、索引基数、预估行数和访问代价选择执行路径。看到“没有使用我创建的索引”时，第一步是把同一条查询交给 EXPLAIN，不要先猜索引名。

-- 先保留原始查询，观察候选索引和实际索引
EXPLAIN
SELECT order_id, customer_id, created_at
FROM orders
WHERE customer_id = 42
  AND created_at >= '2026-11-01';

重点看四列：possible_keys 表示优化器认为可能有用的索引，key 表示最终采用的索引，rows 是估算需要检查的行数，Extra 则补充是否出现回表、排序或其他访问特征。possible_keys 有值而 key 为 NULL，不一定是错误；当结果集很大时，全表扫描可能确实更便宜。

用 USE INDEX 限定候选集合

USE INDEX 写在表名或表别名之后，它告诉 MySQL：从指定索引中选择用于找行的路径。它不是“必须使用其中一个索引”的绝对命令；如果优化器判断这些索引都不合算，仍可能选择表扫描。

-- 只让客户和时间索引进入本次找行的候选范围
EXPLAIN
SELECT order_id, customer_id, created_at
FROM orders USE INDEX (idx_orders_customer_created)
WHERE customer_id = 42
  AND created_at >= '2026-11-01';

索引提示引用的是索引名，不是列名。可以用 SHOW INDEX FROM orders 查看实际名称；复合索引还要结合左前缀判断它是否适合当前谓词。空的 USE INDEX () 语法也有特殊含义，表示不使用索引找行，因此不要把括号省略和空列表混为一谈。

如果查询使用表别名，提示应跟在别名之后；如果把提示放在列列表或 WHERE 后面，语法位置就不对。对多表查询，应把提示绑定到真正需要限制的那张表，避免误以为它会影响整个查询。

用三组 EXPLAIN 判断提示是否有价值

诊断时建议保留三组计划：原始查询、USE INDEX 查询和必要时的 FORCE INDEX 查询。三组结果的差异比“加上提示后看起来更快”更有解释力。

-- 组一：让优化器自由选择
EXPLAIN SELECT * FROM orders
WHERE customer_id = 42 AND created_at >= '2026-11-01';

-- 组二：只缩小候选集合，不强迫放弃表扫描
EXPLAIN SELECT * FROM orders USE INDEX (idx_orders_customer_created)
WHERE customer_id = 42 AND created_at >= '2026-11-01';

-- 组三：只有确认表扫描代价过高时，才单独对照 FORCE INDEX
EXPLAIN SELECT * FROM orders FORCE INDEX (idx_orders_customer_created)
WHERE customer_id = 42 AND created_at >= '2026-11-01';

如果第二组的 key 变成目标索引，但 rows 明显更大，说明提示只是改变了选择，并没有证明索引更合适；如果第三组才改变计划，还要确认它是否只是把一个坏的估算硬压成了另一条路径。生产判断应结合代表性数据、真实参数和实际耗时，不要只凭一份静态计划下结论。

按查询阶段缩小提示作用域

不带 FOR 的索引提示会覆盖找行、排序和分组相关的阶段。MySQL 还支持把作用域写成 FOR JOIN、FOR ORDER BY 或 FOR GROUP BY，适合只修正一个阶段的诊断。

-- 只限制连接和找行阶段，不干预排序索引选择
EXPLAIN
SELECT o.order_id, o.created_at
FROM orders AS o USE INDEX FOR JOIN (idx_orders_customer_created)
WHERE o.customer_id = 42
ORDER BY o.created_at DESC;

这几个作用域不是性能开关。FOR JOIN 影响查找行和连接处理，FOR ORDER BY 面向排序，FOR GROUP BY 面向分组。若一条查询同时有连接、排序和分组，先确定异常发生在哪个阶段，再把提示限制到该阶段，后续维护更容易。

把 USE INDEX 当诊断工具，而不是永久补丁

如果优化器的选择和数据分布明显不符，先检查索引是否真的覆盖过滤条件，再考虑执行 ANALYZE TABLE orders 更新统计信息。统计信息过旧、数据倾斜、谓词选择性变化，都会让优化器的成本估算偏离当前数据。

还要注意版本方向：MySQL 8.4 文档说明，JOIN_INDEX、GROUP_INDEX、ORDER_INDEX 和 INDEX 等索引级优化器提示已提供，并指出它们计划取代 FORCE INDEX；对 USE INDEX 的长期依赖应留出迁移空间，不要把旧提示当成跨版本不变的契约。

上线前可以按这份清单收口：保留无提示的基线计划；记录目标索引为什么更适合；确认提示绑定的是表别名和真实索引名；检查数据量变化后的 rows；评估是否能通过统计信息或索引设计解决；最后再决定是否保留提示。

相关问题

USE INDEX 和 FORCE INDEX 最大区别是什么？

USE INDEX 缩小可选索引集合，但仍允许优化器认为表扫描更合算；FORCE INDEX 额外把表扫描视为代价很高，只有指定索引不可用时才退回。

能不能把列名写进 USE INDEX？

不能。应写索引名，例如 idx_orders_customer_created；先用 SHOW INDEX 确认名称和列顺序。

加了 USE INDEX 还需要 EXPLAIN 吗？

需要。提示改变的是候选范围，不等于证明计划更优；仍要对比 key、rows 和其他计划字段。