force index必须紧接from后，位置错误即报错；索引名须完全匹配且区分大小写，仅当where条件满足最左前缀时才真正生效，否则退化为全表扫描。
FORCE INDEX 语法必须紧接 FROM 后，位置错就报错
MySQL 5.7 中 FORCE INDEX 不是可随意放置的提示，它只接受一种合法位置：紧跟在 FROM table_name 后面，中间不能插任何其他子句或空格。写成 FROM t WHERE ... FORCE INDEX (idx) 或 FROM t USE INDEX (idx) FORCE INDEX (idx) 都会直接报错 ERROR 1064（语法错误）。
正确写法只有这一种形式：SELECT * FROM orders FORCE INDEX (idx_status_created) WHERE status = 'paid'。括号不能省，索引名必须完全匹配 SHOW INDEX FROM orders 输出中的 Key_name 字段（区分大小写，PRIMARY 必须全大写）。
- 常见错误：把索引名写成列名，比如
FORCE INDEX (status)→ 报ERROR 1176 (HY000): Key 'status' doesn't exist - 复合索引必须写全名，
idx_user_id_status不能简写为idx_user_id - 前缀索引（如
INDEX (name(10))）强制时也必须用完整索引名，不能只写name
FORCE INDEX 生效的前提是索引能覆盖 WHERE 条件最左前缀
FORCE INDEX 不等于“让 MySQL 走索引”，它只是强制使用某个索引，但该索引是否真能用于过滤，取决于 WHERE 条件是否满足最左前缀原则。如果强制了 idx_a_b_c，而查询条件是 WHERE c = 1，MySQL 仍会退化为全表扫描——不是语法错，而是逻辑上无法用该索引加速。
验证方式很简单：先用 EXPLAIN 看原语句是否走索引；再加 FORCE INDEX 后再 EXPLAIN，对比 key 和 rows 是否变化。若 key 显示为指定索引但 rows 仍是全表行数，大概率是条件没命中索引结构。
- 函数操作会让强制失效：
WHERE YEAR(created_at) = 2024即使强制idx_created_at，也会跳过索引 - 隐式类型转换也会破坏索引：
WHERE user_id = '123'（user_id 是 INT）可能让idx_user_id失效 -
OR条件中部分分支不走索引，整个 WHERE 可能无法利用强制索引
UPDATE/DELETE 也能用 FORCE INDEX，但风险比 SELECT 高得多
MySQL 5.7 支持在 UPDATE 和 DELETE 语句中使用 FORCE INDEX，语法结构一致，但影响更隐蔽：它不仅决定扫描路径，还直接影响锁范围、回表次数和 undo log 生成量。
例如 UPDATE logs FORCE INDEX (idx_device_id_ts) SET status = 'done' WHERE device_id = 123 AND ts > '2026-06-01'，如果 idx_device_id_ts 不是覆盖索引，MySQL 会先通过索引定位记录，再回主键查出所有字段做判断和更新——这比 SELECT 多出大量随机 IO 和锁等待。
- 没有
EXPLAIN UPDATE，只能用等价SELECT模拟：把UPDATE的 WHERE 条件单独拎出来EXPLAIN SELECT *查看执行计划 - 线上执行前务必在从库压测，避免因锁升级导致主库阻塞
- 特别注意：
FORCE INDEX对ORDER BY ... LIMIT场景影响显著，可能改变排序方式（索引有序 vs 文件排序），进而影响结果稳定性
FORCE INDEX 是临时手术刀，不是长期索引治理方案
它解决的是“优化器当前选错”这个瞬时问题，不是替代索引设计或统计信息维护的手段。一旦索引被重命名、删除，或数据分布发生显著变化（比如某值占比从 5% 涨到 80%），原来有效的 FORCE INDEX 就可能变成性能瓶颈甚至故障源。
真正可持续的做法是：先跑 ANALYZE TABLE 更新统计信息；检查是否有更优的复合索引可建；确认查询条件是否可改写避免函数/类型转换。只有当这些都试过且无效，才把 FORCE INDEX 当作线上紧急绕过的最后选项，并配上明确注释和监控告警。
最容易被忽略的一点：多个 JOIN 表时，FORCE INDEX 只对单表生效，必须对每个需要干预的表分别写，比如 JOIN events e FORCE INDEX (idx_ts) ON ...，漏掉任何一个都可能让整体计划劣化。
