force index 可能被优化器降级为 use index 甚至忽略，主因是索引无法满足 where 条件（如函数操作、类型不匹配、最左前缀未命中）、统计信息过期、分区/json/全文索引限制或优化器参数配置不当。
FORCE INDEX 被降级为 USE INDEX，不是语法错了
你写的 FORCE INDEX (idx_name) 没报错，但执行计划里 key 字段为空、rows 高得离谱，甚至 Extra 里还写着 “Using where; Using index”，这不代表走索引了——它大概率已被优化器悄悄降级成 USE INDEX，然后被无视。根本原因不是你写错了，而是优化器在内部判定：这个索引压根无法满足 WHERE 条件过滤，强制走它代价更高，于是“合规地绕过”你的指令。
常见触发点包括：
-
WHERE中对索引列用了函数，比如YEAR(created_at) = 2024——created_at上有索引也没用 - 字段类型不匹配，比如
phone VARCHAR(20)索引，却写WHERE phone = 13800138000，触发隐式转换 - 联合索引
(a,b,c)，而条件是WHERE b = 1 AND c = 2，最左前缀没命中，该索引根本不在候选列表里
索引统计信息过期，优化器“算错账”
优化器依赖 INFORMATION_SCHEMA.STATISTICS 和采样估算行数。如果表刚批量导入百万行，或删除了大量旧数据，但没运行 ANALYZE TABLE，它可能还认为你查的是“小表”，直接选全表扫描更省事——哪怕你 FORCE INDEX 了，它也照旧跳过。
验证方法很简单：
- 执行
SHOW INDEX FROM table_name，看Cardinality是否明显偏离实际唯一值数量 - 对比
EXPLAIN FORMAT=TREE（MySQL 8.0+）中各节点的estimated_rows和真实结果集大小 - 临时执行
ANALYZE TABLE table_name，再跑一遍EXPLAIN，看key是否终于非空
分区表、JSON 字段和全文索引的特殊失效场景
FORCE INDEX 在这些场景下行为异常，不是 bug，而是设计限制：
- 分区表上，
FORCE INDEX只对匹配的分区生效；其他分区仍可能全扫——必须配合PARTITION (p2024, p2025)显式限定 - JSON 字段即使建了虚拟列 + 索引，如
gen_id INT AS (json_extract(data, '$.id')) STORED，WHERE gen_id = ?才能真正让FORCE INDEX有意义；直接WHERE data->'$.id' = 1基本无效 - MySQL 5.7 中
FORCE INDEX对全文索引完全无效；8.0+ 支持MATCH ... AGAINST强制，但必须带IN NATURAL LANGUAGE MODE，否则报错ERROR 1193
配置参数会默默干扰 FORCE INDEX 的底层决策
有些全局设置会让优化器“不敢”或“不能”按你写的索引走：
-
optimizer_search_depth设得太低（比如 3），复杂 JOIN 下优化器来不及评估所有索引组合，直接 fallback 到全表扫描 -
range_optimizer_max_mem_size=0会禁用 range 计划，导致本该走索引范围扫描的查询，被迫选错路径 -
innodb_stats_persistent_sample_pages过小（默认 20），统计采样不准，小表误判成大表，或高选择性索引被低估
真正容易被忽略的点是：这些参数影响的是“FORCE INDEX 能否进入候选执行计划”，而不是“是否最终被选中”。没进候选列表，再怎么 FORCE 也没意义。调参前务必用 EXPLAIN FORMAT=TREE 看完整计划树，别只盯着 Extra。
