FORCE INDEX真正生效需同时满足：EXPLAIN中key列显示指定索引名、type从ALL升至ref/range、rows显著下降；否则多因索引名错误、表别名误用或索引不存在。
FORCE INDEX在EXPLAIN里怎么看出它真起了作用
加了FORCE INDEX却没效果，最常见的原因是MySQL直接报错或静默忽略。必须确认三件事：EXPLAIN输出的key列是否等于你写的索引名；type是否从ALL变成ref/range；rows值有没有显著下降。如果key还是NULL，大概率是索引名拼错、表用了别名但提示写在原表名后、或者该索引根本不存在（比如刚建完没刷元数据缓存）。
加FORCE INDEX后rows反而变大，说明什么
这是最危险的信号——你强制它走了一条更重的路径。常见于以下情况：
– 强制走了覆盖度低的索引，导致回表次数暴增；
– 联合索引顺序和查询条件不匹配，例如FORCE INDEX(idx_a_b)但只查WHERE b = 1，实际只能用上b字段的索引下推部分，而优化器原本选的单列idx_b更高效；
– 数据分布突变（如某状态值占比从5%飙升到95%），强制索引让优化器绕过了统计信息修正机会。此时应先运行ANALYZE TABLE table_name，再对比原语句和强制语句的EXPLAIN。
FORCE INDEX和隐藏索引一起用会怎样
MySQL 8.0中，FORCE INDEX对隐藏索引默认无效，会直接报错ERROR 1176 (HY000): Key 'xxx' doesn't exist in table。想验证隐藏索引的影响，必须先启用use_invisible_indexes=on（通过SET SESSION optimizer_switch='use_invisible_indexes=on'），否则FORCE INDEX连语法校验都过不去。这说明：强制索引不是万能开关，它依赖索引在当前会话中“可见且可用”，而隐藏索引本质是让优化器“假装看不见”，不是物理删除。
什么时候该删掉FORCE INDEX而不是保留它
FORCE INDEX是临时诊断手段，不是上线方案。以下情况必须删：
– EXPLAIN显示Extra里出现Using filesort或Using temporary，说明强制索引破坏了排序/分组路径；
– 同一SQL在不同参数值下表现不稳定（比如user_id = 123快，user_id = 456慢），暴露的是数据倾斜或统计信息不准，不是索引本身问题；
– 应用里混用USE INDEX和FORCE INDEX，但USE INDEX已被优化器忽略，说明底层索引设计或数据模型存在缺陷，该重构而非打补丁。
