force index 强制绑定索引名，导致表结构变更时报错、数据分布变化时性能断崖下跌、绕过优化器成本估算、update/delete中扩大锁范围且难以诊断，并掩盖索引设计缺陷。
FORCE INDEX 会锁死索引选择逻辑，数据变化后立即失效
它把执行计划和某个具体索引名强绑定，一旦表结构变更（比如索引重命名、重建、或被ANALYZE TABLE触发元数据刷新），所有含该FORCE INDEX的 SQL 都可能直接报错ERROR 1176 (HY000): Key 'xxx' doesn't exist in table。更隐蔽的是：数据倾斜加剧、查询条件分布偏移（如某status值占比从5%涨到80%），原来高效的索引可能变成最差选择，但FORCE INDEX还在硬推——这时性能断崖式下跌，且很难第一时间归因。
它绕过优化器的自适应能力，无法响应运行时统计更新
MySQL 优化器会根据INFORMATION_SCHEMA.STATISTICS里的行数、基数、直方图等动态估算成本，而FORCE INDEX完全跳过这一步。即使你刚跑完ANALYZE TABLE，优化器已生成更优计划，FORCE INDEX仍强制走旧路径。某些版本（如 MySQL 8.0.33+）还会缓存带FORCE INDEX的执行计划，导致统计更新后计划也不重编译——必须FLUSH TABLES或重启连接才能生效，线上几乎不可控。
UPDATE/DELETE 中 FORCE INDEX 风险远高于 SELECT
-
UPDATE orders FORCE INDEX (idx_user_id) SET status = 'done' WHERE user_id = 123看似安全，但若该索引不是覆盖索引，MySQL 仍需回表读取整行再加锁，锁范围可能从单行扩大为索引区间 - 二级索引更新会触发额外的 undo log 写入和 buffer pool 刷脏，QPS 高时极易引发
Lock wait timeout exceeded - 没有
EXPLAIN UPDATE，只能靠模拟等价SELECT+SHOW PROFILE推断，实际压测成本高、漏判风险大
真正容易被忽略的是：它掩盖了索引设计缺陷本身
频繁依赖FORCE INDEX往往说明联合索引顺序不合理、缺失覆盖字段、或谓词写法触发隐式转换（如WHERE created_at > '2024-01-01'写成WHERE DATE(created_at) = '2024-01-01'）。这些本该通过重构查询或调整索引解决的问题，被当成“临时补丁”长期挂着，最终演变成技术债黑洞——没人敢动那条 SQL，因为不知道去掉FORCE INDEX后会不会雪崩。
