MySQL有时不走期望索引是因优化器基于过期统计、数据倾斜或谓词条件误判成本，如WHERE a=? AND b>?时弃用联合索引(a,b)而选单列索引a；FORCE INDEX可强制使用指定索引，但仅在索引逻辑有效时生效，否则静默忽略或报错。
MySQL为什么有时不走你期望的索引
MySQL优化器在生成执行计划时，会基于统计信息估算成本，但统计可能过期、数据分布倾斜、或谓词条件让优化器误判——比如 WHERE a = ? AND b > ? 场景下，它可能选了单列 a 索引而非更优的联合索引 (a, b)。这不是bug，是代价模型在特定数据量/分布下的合理误判。
常见现象包括：EXPLAIN 显示 type: ALL（全表扫描）或 key: NULL，而你知道存在覆盖查询条件的索引；或者明明有 ORDER BY x LIMIT 10，却没走 x 上的索引。
FORCE INDEX 能解决什么，不能解决什么
FORCE INDEX 是告诉优化器：“必须用这个索引，别犹豫”，但它不改变索引本身的有效性——如果强制的索引根本无法满足 WHERE 条件（比如没包含所有等值谓词列），MySQL 仍会回退为全表扫描，并报错 ERROR 1176 (HY000): Key 'xxx' doesn't exist in table（仅当该索引确实不存在时）；更常见的是静默忽略并选其他索引，只要语法合法。
使用场景明确：已确认某索引逻辑上可支撑查询，且实测比优化器自选更快；临时绕过统计不准导致的劣质执行计划；线上紧急止损，来不及改索引或收集统计。
注意：FORCE INDEX 不影响索引合并（index merge）、也不保证覆盖扫描（covering index），是否回表仍取决于 SELECT 列和索引结构。
-
FORCE INDEX (idx_a_b)：只强制使用该索引，但优化器仍可决定是否用它做排序或范围扫描 -
USE INDEX (idx_a_b)：建议使用，不强制；IGNORE INDEX (idx_old)：排除某个索引 - 不能对
JOIN中的右表（被驱动表）单独 force，必须写在对应表的FROM子句后
怎么写才不报错、不被忽略
语法必须紧贴表名，且索引名拼写完全匹配 SHOW INDEX FROM tbl 输出的 Key_name 字段（区分大小写，取决于系统变量 lower_case_table_names）。多表 JOIN 时，每个表的 FORCE INDEX 需独立声明。
SELECT * FROM orders FORCE INDEX (idx_status_created) WHERE status = 'shipped' AND created_at > '2024-01-01';
SELECT u.name, o.total FROM users u FORCE INDEX (PRIMARY) JOIN orders o FORCE INDEX (idx_user_id_status) ON o.user_id = u.id WHERE u.active = 1 AND o.status = 'paid';
容易踩的坑：
- 索引名写错或用了字段名（如
FORCE INDEX (user_id)而非真实索引名idx_user_id）→ 直接报错 - 在视图或子查询中使用
FORCE INDEX，部分旧版本 MySQL 不支持 → 检查版本是否 ≥ 5.7.3 - 用
FORCE INDEX后EXPLAIN显示key是预期索引，但rows极高 → 实际仍是全索引扫描，需结合SELECT列判断是否覆盖
比 FORCE INDEX 更可持续的替代方案
强制指定是手术刀，不是创可贴。长期依赖它，意味着统计信息、索引设计或查询写法存在隐患。
优先检查这几件事：
- 运行
ANALYZE TABLE tbl更新统计信息，尤其在大批量导入/删除后 - 用
EXPLAIN FORMAT=JSON查看优化器“为什么放弃你的索引”——常暴露在considered_execution_plans或condition_filtering_pct - 确认联合索引顺序是否匹配查询模式：等值条件列在前，范围/排序列在后，例如
WHERE a = ? AND b > ? ORDER BY c→ 索引应为(a, b, c) - 避免在索引列上用函数或计算，如
WHERE YEAR(created_at) = 2024会让索引失效
真正难处理的是数据极度倾斜（比如 99% 的 status = 'pending'），此时优化器认为全表扫描比走索引再过滤更便宜——这种情况下，FORCE INDEX 是最直接的干预手段，但也得同步考虑分区或冗余索引。
