IGNORE INDEX 是唯一能直接让 MySQL 优化器跳过指定索引的语法，但必须紧贴 FROM 子句后、索引名准确且该索引已在 possible_keys 中，否则报错或静默失效；它适用于已确认优化器选错索引的调试场景，而非长期生产方案。
IGNORE INDEX 是唯一能直接让 MySQL 优化器跳过指定索引的语法，但它不是“随便一写就生效”的开关，而是需要严格满足位置、语法和前提条件的语句级提示。
IGNORE INDEX 的正确写法和位置要求
它必须紧贴 FROM 子句之后，且不能出现在 WHERE、ORDER BY 或子查询里。写错位置会导致报错或静默失效。
-
SELECT * FROM t1 IGNORE INDEX (idx_a) WHERE a = 1—— ✅ 正确（MySQL 8.0+ 兼容） -
SELECT * FROM t1 WHERE a = 1 IGNORE INDEX (idx_a)—— ❌ 报错 ERROR 1064 -
SELECT * FROM (SELECT * FROM t1 IGNORE INDEX (idx_a)) t2—— ❌ 子查询里的IGNORE INDEX不会传递到外层 - 带表别名时，提示要放在别名前：
SELECT * FROM t1 AS a IGNORE INDEX (idx_a) WHERE a.x = 1
什么时候才该用 IGNORE INDEX？
只在你已确认优化器选错了索引，且 EXPLAIN 显示异常时才考虑。典型信号包括：
-
EXPLAIN中key列显示用了某个索引，但rows高得离谱（比如扫描 50 万行，实际只返回 3 行） -
type是range或ref，但执行时间比全表扫描还长 - 复合索引中，优化器选了区分度低的前导列（如
INDEX (status, created_at)，而WHERE status = 'pending'占比 95%） - 已执行过
ANALYZE TABLE，排除统计信息过期干扰
IGNORE INDEX 容易失效的三种情况
写了却没效果？大概率掉进下面这些坑：
- 试图忽略主键或唯一索引后，查询仍走索引：MySQL 可能因约束检查或覆盖需求绕过你的提示（例如
WHERE id = ?忽略PRIMARY后退化为ALL，但若语句含SELECT *，它可能仍悄悄用主键回表） - 索引名拼错或大小写不匹配：
IGNORE INDEX (IDX_USER_ID)对不上实际定义的idx_user_id（MySQL 默认大小写敏感） - 目标索引根本不在
possible_keys列表里：EXPLAIN显示possible_keys: NULL，说明该索引压根没被优化器考虑过，IGNORE INDEX自然无从谈起
FORCE INDEX 比 IGNORE INDEX 更可控
IGNORE INDEX 是减法操作——告诉优化器“别用这几个”，但没指明“该用哪个”。剩下索引都不合适时，它可能 fallback 到全表扫描，你还得额外验证。
- 有明确更优索引时，优先用
FORCE INDEX (idx_better)，它会强制走指定路径，只要该索引能覆盖查询条件，行为就稳定 -
FORCE INDEX在 MySQL 5.0+ 全版本支持；IGNORE INDEX从 5.1 开始支持，但 5.1.12 前不支持多索引列表（如IGNORE INDEX (a,b)） - 分区表上，
IGNORE INDEX对全局二级索引有效，但对本地索引是否真正跳过，需结合EXPLAIN PARTITIONS验证
真实场景中，IGNORE INDEX 多用于临时调试或灰度验证，而不是长期上线逻辑。它生效的前提是你已经看懂 EXPLAIN 输出、知道数据分布、并确认没有更简单的替代方案（比如改写 WHERE 条件、补统计信息、删冗余索引）。否则，加一个提示反而让 SQL 变得脆弱又难维护。
