force index 不保证性能提升，仅强制走指定索引路径，可能因回表开销大、选择性差或锁范围扩大而恶化性能，须先确保索引设计合理且能被逻辑使用。
FORCE INDEX 本身不保证性能提升，只强制走索引路径
它不是“加速开关”，而是“绕过优化器决策”的指令。当优化器原本选的是全表扫描，而你强制它走一个低效索引时，MySQL 就会老老实实按你写的来——哪怕要回表上万次、读取大量无效数据页。这种情况下，FORCE INDEX 只是把“慢得合理”变成了“慢得确定”。
回表代价远超预期：非覆盖索引 + 高命中行数 = 性能雪崩
常见于 SELECT * 或查询列未被索引完全覆盖的场景。比如强制走 idx_user_id（仅含 user_id），但 WHERE 条件匹配了 5 万行，而你要的 status、created_at 都不在该索引里——MySQL 就得拿着这 5 万个主键，逐个去聚簇索引里随机 IO 查完整行。SSD 随机读都扛不住，更别说机械盘。
- 用
EXPLAIN FORMAT=TRADITIONAL看key和rows，再比对SELECT COUNT(*)实际返回行数；若二者接近，且Extra含Using where; Using index condition，说明大概率在回表 - 检查索引是否覆盖：用
SHOW INDEX FROM table_name确认idx_user_id的Column_name列是否包含所有 SELECT 和 WHERE 中涉及的字段 - 临时方案：改写为
SELECT user_id FROM ... FORCE INDEX (idx_user_id) WHERE ...，确认索引扫描本身是否快；再逐步加回其他字段判断瓶颈点
索引选择性差 + 强制使用 = 主动放弃优化器的理性判断
比如对只有两个值的 status 字段建了单列索引 idx_status，优化器估算扫一半数据还不如全表顺序读——这是对的。此时加 FORCE INDEX (idx_status)，只会让 MySQL 放弃自己正确的成本判断，硬着头皮走一棵几乎没过滤能力的树，叶子节点密密麻麻全是有效记录，B+ 树优势荡然无存。
- 用
SELECT COUNT(DISTINCT status) / COUNT(*) AS selectivity FROM orders;算选择性；低于 0.05 基本不适合单独建索引 - 联合索引中把低选择性字段放最右，比如
(user_id, created_at, status)，强制时才可能真正受益 - 别在
WHERE status IN ('paid', 'shipped')这类查询上强行指定单列idx_status，优化器弃用它往往是对的
线上执行前漏掉关键验证：没模拟等价 SELECT 或忽略锁行为
FORCE INDEX 在 UPDATE 或 DELETE 中尤其危险。它不会减少锁范围，反而可能扩大——比如强制走 idx_device_id 更新设备状态，但该索引不包含 last_seen 字段，MySQL 就得先通过索引定位，再回表读旧值做条件判断，最后加行锁更新。整个过程锁住的不只是目标行，还可能波及相邻数据页。
- 任何带
FORCE INDEX的 DML，必须先写等价SELECT ... FORCE INDEX (...) WHERE ...并跑EXPLAIN ANALYZE（8.0+）或SHOW PROFILE看真实耗时 - 在从库或低峰期用
SELECT ... FOR UPDATE模拟锁行为，观察是否出现长等待 - 别信
EXPLAIN的rows估值——它常严重低估回表开销，务必结合慢日志里的Query_time和Lock_time看实际表现
最易被忽略的一点：FORCE INDEX 解决的是“优化器误判”，不是“索引设计缺陷”。如果查询本身 WHERE 条件就违背最左前缀、或存在隐式转换、或用了函数，加了 FORCE 也白搭——MySQL 会直接报错或静默退化。先确保索引逻辑上能用，再谈要不要强制。
