FORCE INDEX 仅对 SELECT 有效，不能用于 INSERT/UPDATE/DELETE；DML 语句中使用会报错或被忽略，其索引选择由优化器依据 WHERE 条件、统计信息等自动决定。
FORCE INDEX 不能用于 DML 语句（INSERT / UPDATE / DELETE）的索引强制指定——它只对 SELECT 有效。 想在写操作中“指定索引”本质上是个误解，MySQL 不提供该能力，强行尝试会报错或被忽略。
FORCE INDEX 只支持 SELECT，用在 INSERT/UPDATE/DELETE 上会失效
MySQL 的 FORCE INDEX 是优化器提示（hint），仅作用于查询执行计划生成阶段。DML 语句中的数据修改逻辑不走“查询路径”，因此：
-
INSERT ... FORCE INDEX (...)语法错误，MySQL 直接报ERROR 1064 -
UPDATE t SET x=1 WHERE y=2 FORCE INDEX (idx_y)会被忽略，语句能执行但FORCE INDEX不生效 -
DELETE FROM t WHERE id=1 FORCE INDEX (PRIMARY)同样被 parser 忽略，EXPLAIN EXTENDED 也看不到 hint 影响
UPDATE/DELETE 实际走什么索引？看 WHERE 条件和可用索引
DML 中的索引选择完全由优化器决定，依据是 WHERE 子句字段、索引覆盖度、统计信息和成本估算。你无法“命令”它用某个索引，但可以间接影响：
- 确保 WHERE 字段上有合适索引（如
UPDATE users SET status=1 WHERE created_at 应有 <code>created_at索引） - 避免在 WHERE 中对索引列做函数操作：
WHERE YEAR(created_at)=2023会让索引失效 - 用
EXPLAIN FORMAT=TRADITIONAL分析对应 SELECT 语句，它和 UPDATE/DELETE 的索引选择通常一致 - 更新大量行时，MySQL 可能放弃索引走全表扫描——这是成本权衡，不是 bug
想“控制”写操作性能？重点在索引设计和语句写法
与其试图强制索引，不如从源头减少优化器误判：
- 为高频 UPDATE/DELETE 的 WHERE 条件单独建联合索引，例如
ALTER TABLE orders ADD INDEX idx_status_created (status, created_at) - 避免在 DML 中混用 OR、子查询或复杂表达式，它们容易让优化器放弃索引
- 定期运行
ANALYZE TABLE更新统计信息，防止因过期统计导致选错索引 - 若某条 UPDATE 性能骤降，先查
SHOW PROFILE或慢日志，确认瓶颈是否真在索引选择——很多时候是锁等待或 I/O 压力
真正需要“强制”的场景极少，多数时候是索引缺失或查询条件写法不当。别把 FORCE INDEX 当万能开关，它解决不了 DML 的底层执行机制限制。
