FORCE INDEX仅在优化器误判（如全表扫描或选错索引）且你确认存在更优索引时才真正有效；它不是提速万能键，而是对统计失真、隐式转换等场景的兜底干预。
FORCE INDEX 什么时候真有用
当 EXPLAIN 显示 MySQL 选了全表扫描，或者用了低效索引（比如只用到联合索引的中间字段），而你确认有更合适的索引可用时，FORCE INDEX 才值得介入。它不是“加了就快”，而是对优化器误判的兜底手段。
常见误用场景包括：
- 在
WHERE条件里字段类型不一致（如INT关联VARCHAR），导致索引失效——这时加FORCE INDEX没用，必须先修复类型匹配 - 查询返回大量字段，但目标索引是单列索引，无法覆盖查询所需列——强制后仍要回表，性能提升有限
- 数据量极小（比如几百行），全表扫描比走索引还快，强制反而拖慢
FORCE INDEX 和 USE INDEX 的关键区别
FORCE INDEX 是硬性指令：即使优化器评估走这个索引成本更高，也会执行；USE INDEX 只是建议，优化器仍可能无视它去选全表扫描。
实操中优先试 USE INDEX，只有确认优化器“固执地拒绝”合理索引时，再升级为 FORCE INDEX。例如：
SELECT u.name, o.total FROM users u USE INDEX (PRIMARY) JOIN orders o ON u.id = o.user_id WHERE o.status = 1;
如果这条语句仍没走 PRIMARY，再改成：
SELECT u.name, o.total FROM users u FORCE INDEX (PRIMARY) JOIN orders o ON u.id = o.user_id WHERE o.status = 1;
多表 JOIN 时 FORCE INDEX 容易踩的坑
MySQL 对每个表单独应用 FORCE INDEX，但它不控制 JOIN 顺序。如果你强制了 A 表的索引，但优化器先扫了 B 表（且 B 表没过滤条件），A 表的索引再好也白搭。
此时需配合 STRAIGHT_JOIN 或 MySQL 8.0+ 的 Hint：
- 老版本：把过滤最强的表放最左，并在其上
FORCE INDEX - MySQL 8.0+：用
/*+ STRAIGHT_JOIN */注释 + 多个FORCE INDEX组合 - 避免对 JOIN 条件中非驱动表的字段强制索引（比如
ON a.id = b.a_id，对b.a_id强制索引有效，但对b.other_col强制通常无效）
为什么有时候 FORCE INDEX 后反而变慢
根本原因常是索引本身不适合该查询路径。典型情况包括：
- 强制的索引是
(a, b)，但查询只用WHERE b = ?—— 最左前缀不满足，实际还是全扫 - 强制索引字段区分度极低（如
status TINYINT），导致大量回表，I/O 暴涨 - 查询含
ORDER BY或GROUP BY，而强制的索引不包含这些字段，触发Using filesort或Using temporary - 表有分区，但
FORCE INDEX没配合PARTITION(p1,p2)，仍扫描全部分区
遇到变慢，第一反应不是换别的索引，而是用 EXPLAIN FORMAT=JSON 看实际是否真走了强制索引、有没有回表、是否触发临时表——很多“强制失败”其实压根没生效。
