MySQL 8.0 不支持 NO_INDEX 提示，正确灰度验证路径是“隐藏索引+SET_VAR临时启用”，通过对比 EXPLAIN 的 key/rows/type 变化评估索引必要性，IGNORE INDEX 因语句级局限无法替代。
不能用 NO_INDEX 提示来“禁用”某个索引做灰度验证——MySQL 8.0 不支持这个语法，直接执行会报错 ERROR 1064 (42000)。
MySQL 没有 NO_INDEX 这个索引提示
官方文档和源码中均无 NO_INDEX 提示。你可能混淆了以下两类机制：
-
IGNORE INDEX或USE INDEX：这是「索引提示（Index Hints）」，作用于单条语句，语法为SELECT ... FROM t IGNORE INDEX (idx_name) WHERE ... -
use_invisible_indexes=on：这是 optimizer_switch 开关，配合隐藏索引使用，属于「优化器提示（Optimizer Hints）」范畴，但本身不是索引级提示
试图写 SELECT /*+ NO_INDEX(t1, idx_name) */ ... 会触发解析错误，因为 MySQL 不识别该 hint 名称。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
想验证某个索引是否必要，正确路径是「隐藏 + 对比」
核心逻辑不是“强行绕过”，而是让索引存在但默认不参与优化决策，再精准激活它做执行计划对比：
- 先创建或修改目标索引为隐藏：
ALTER TABLE users ALTER INDEX idx_email INVISIBLE; - 确认状态：
SELECT index_name, is_visible FROM information_schema.statistics WHERE table_name = 'users' AND index_name = 'idx_email';—— 返回NO才生效 - 用 SQL 提示临时启用它：
SELECT /*+ SET_VAR(optimizer_switch = 'use_invisible_indexes=on') */ * FROM users WHERE email = 'a@b.com'; - 分别对带/不带该提示的语句执行
EXPLAIN，重点比对key、rows、type字段变化
为什么不用 IGNORE INDEX 替代隐藏索引？
IGNORE INDEX 看似简单，但它在真实线上验证中存在硬伤：
- 它只对当前这条 SQL 生效，无法覆盖应用中所有可能走该索引的查询路径（比如 ORM 自动生成的语句、不同参数的 WHERE 组合）
- 无法观测写入开销：即使你
IGNORE了某个索引，INSERT/UPDATE/DELETE仍会维护它——而隐藏索引同样维持写入成本，这点二者一致，但IGNORE完全不反映读路径被关闭后的整体负载变化 - 无法结合
performance_schema做聚合分析：你没法用events_statements_summary_by_digest统计“所有用了idx_email的语句”在禁用前后的耗时漂移，因为IGNORE是语句级硬编码，digest 值已不同
容易忽略的关键细节
隐藏索引验证不是一锤子买卖。上线前必须确认三件事：
-
PRIMARY KEY和隐式主键（如第一个UNIQUE NOT NULL索引）永远不能设为隐藏，尝试会报ER_PRIMARY_CANT_BE_INVISIBLE - 哪怕索引被设为
INVISIBLE，只要表上有FOREIGN KEY引用它，DROP INDEX仍会被拒绝——需先删外键或改引用 - 某些监控工具（如 pt-query-digest）若依赖
information_schema中的IS_VISIBLE = YES来过滤索引列表，会直接漏掉隐藏索引，导致误判“该索引已不存在”
