必须用 FORCE INDEX 的情况是：MySQL 优化器因选择性误判、统计信息过期或复合索引不匹配而放弃可用索引，导致全表扫描（EXPLAIN 显示 type=ALL），且你已确认索引合理、数据分布利于索引查找。
什么情况下必须用 FORCE INDEX 才能走索引
MySQL 优化器判断 WHERE 条件选择性低（比如字段重复值多、或统计信息过期），或者执行计划中预估扫描行数远小于实际时，会放弃走索引而选全表扫描。典型表现是 EXPLAIN 显示 type=ALL，但你知道该字段上有合适索引且数据分布利于索引查找——这时才需要干预。
- 常见于大表上对低基数字段（如
status TINYINT）查询，优化器认为“扫完再过滤”比“回表取数据”更便宜 -
ANALYZE TABLE没有及时更新，导致统计信息陈旧，优化器误判 - 复合索引顺序与查询条件不完全匹配，优化器退化为只用前缀或弃用索引
FORCE INDEX 和 USE INDEX 的关键区别
FORCE INDEX 表示“必须走这个索引，哪怕要全表扫描也得先走它”，而 USE INDEX 只是“从这几个索引里选，别考虑其他索引”，优化器仍可能跳过它（比如发现该索引无法覆盖 WHERE 条件）。所以当你要确保索引生效，尤其在 JOIN 或子查询中，FORCE INDEX 更可靠。
-
FORCE INDEX (idx_user_status)：如果idx_user_status不满足WHERE条件，语句直接报错ERROR 1176: Key 'idx_user_status' doesn't exist in table 'users' -
USE INDEX (idx_user_status)：即使该索引不适用，也会退回到全表扫描，不报错 - 两者都不影响
ORDER BY或GROUP BY是否使用索引，除非显式写进 hint
在 JOIN 中强制指定驱动表索引的写法
多表关联时，优化器可能把本该走索引的小表当成被驱动表，导致嵌套循环代价飙升。此时需在对应表的 FROM 子句后立刻加 hint，且必须写对表别名（如果用了别名）。
SELECT u.name, o.amount FROM users FORCE INDEX (idx_users_id) u JOIN orders FORCE INDEX (idx_orders_user_id) o ON u.id = o.user_id WHERE u.status = 1 AND o.created_at > '2024-01-01';
- hint 必须紧贴表名/别名之后，不能放在
JOIN关键字后 - 如果
orders表没建idx_orders_user_id，这条语句会报错，不是静默忽略 - 若用的是视图或派生表，hint 对原表无效，需在视图定义里加，或改用物化临时表
容易被忽略的副作用和限制
强制索引不是银弹。它绕过了优化器的成本估算，一旦数据分布变化（比如某状态值突然暴涨十倍），原本高效的索引可能变成性能黑洞，而且这种问题不会报错，只会变慢。
- 分区表中，
FORCE INDEX不会自动适配分区裁剪，可能扫多个分区；需配合PARTITION (p2024)显式指定 - 在
UPDATE/DELETE语句中可用，但 MySQL 5.7+ 要求 hint 写在UPDATE关键字后、表名前，格式为UPDATE FORCE INDEX (...) t SET ... - 复制环境中，如果从库的索引结构和主库不一致（比如少一个索引），带
FORCE INDEX的语句在从库会失败
真正该加 hint 的时候，往往是优化器失效 + 你已确认索引设计合理 + 数据特征稳定。否则优先检查统计信息、索引覆盖、字段类型隐式转换这些更底层的问题。
