force index能绕过优化器错误选择，是因为它跳过成本估算、直接硬性约束执行路径；仅当优化器本该用却未选某索引（如explain显示type=all而条件明显匹配索引）时才有效，否则无效或报错。
FORCE INDEX 为什么能绕过优化器的错误选择
MySQL优化器有时会基于过时的统计信息或简单模型，误判索引效率，比如在 WHERE 条件明显可走索引的情况下，却选了全表扫描；或者在多索引共存时，选了区分度低、实际更慢的那个。这时 FORCE INDEX 不是“教优化器怎么选”，而是直接跳过它的估算环节，强制使用指定索引——它不参与成本计算，只做执行路径的硬性约束。
注意：FORCE INDEX 不等于“一定更快”。如果索引本身不适合查询模式（比如覆盖不足、回表严重），强制后反而更慢。它解决的是“该用没用”的偏差，不是“用了但不好”的性能问题。
FORCE INDEX 的正确写法和常见拼写陷阱
FORCE INDEX 必须写在 FROM 子句的表名之后，紧跟括号，括号内是索引名（不是列名），多个索引用逗号分隔。容易出错的地方包括：
- 把索引名写成列名，例如
FORCE INDEX (create_time)（错误）→ 实际应为FORCE INDEX (idx_create_time)（假设索引名为此） - 忽略索引名大小写：MySQL 在 Linux 下索引名区分大小写，
FORCE INDEX (IDX_USER_ID)和FORCE INDEX (idx_user_id)可能不等价 - 对 JOIN 表漏写别名导致语法报错：若写了
FROM users u FORCE INDEX (idx_status)，后续ON u.id = orders.user_id中必须用u，不能混用users - 在子查询或视图中使用时，
FORCE INDEX只作用于该层表，不会透传
示例：
SELECT * FROM orders FORCE INDEX (idx_status_created) WHERE status = 'shipped' AND created_at > '2024-01-01';
什么时候该用 FORCE INDEX，而不是 ANALYZE TABLE 或重写查询
优先考虑 FORCE INDEX 的典型场景有：
- 线上突发慢查，临时救急，来不及收集统计信息或修改 SQL 逻辑
- 查询条件固定、数据分布长期稳定，但优化器因采样偏差反复选错（如某状态值占比突变但
ANALYZE TABLE没触发） - 联合索引顺序与查询条件不完全匹配，优化器放弃使用，但你知道前导列足够过滤（例如索引是
(a, b, c)，查询只用WHERE a = ?，优化器可能因评估过滤率低而弃用，但实际a区分度很高） - 分区表中跨分区查询，优化器误估分区裁剪效果，用
FORCE INDEX配合WHERE可辅助定位到有效分区
反例：如果 EXPLAIN 显示已走了正确索引但依然慢，问题大概率在回表、排序、网络传输或锁竞争，此时加 FORCE INDEX 无意义。
FORCE INDEX 的副作用和监控要点
强制索引会屏蔽优化器的自适应能力，后续数据增长或索引变更可能导致原本合理的强制变成瓶颈。上线后必须关注：
- 执行计划是否真按预期走了该索引（检查
EXPLAIN的key列是否为指定名，且type是ref/range而非ALL） - 对比强制前后的
rows和filtered值：若rows暴涨，说明索引实际过滤效果差，只是被硬绑住了 - 监控该语句的
Handler_read_*状态变量，特别是Handler_read_next和Handler_read_rnd_next是否异常升高（回表过多） - 避免在 ORM 自动生成的 SQL 中硬编码
FORCE INDEX，除非框架支持安全注入（如 MyBatis 的<bind></bind>+ 白名单校验）
最易被忽略的一点：MySQL 8.0.19+ 对某些带函数索引或隐藏索引的场景，FORCE INDEX 可能静默失效——务必在目标版本上实测 EXPLAIN 输出。
