MySQL 8.0与5.7版本索引新特性详解：不可见索引与函数索引有哪些区别？

本文共计1341个文字，预计阅读时间需要6分钟。

MySQL 8.0 的索引能力相较于 5.7 有实质性提升，并非简单的小修小补。不可见索引（INVISIBLE INDEX）和函数索引（FUNCTIONAL INDEX）是两项实用的新特性，但它们的使用条件、生效逻辑及常见误用等非规范化——使用 EXPLAIN 查看，可能看不到效果，线上仍可能性能退步。

不可见索引：软删除和灰度发布的底层支撑

不可见索引不是“禁用”，而是让优化器默认忽略它，但后台仍持续维护（写入、更新、B+树分裂等照常发生）。这意味着你删错索引的风险归零，也无需为测试新索引而停业务。

• 主键绝对不能设为不可见：哪怕显式加 INVISIBLE，MySQL 会直接报错 ERROR 3092 (HY000): The primary key cannot be invisible
• 唯一索引有隐藏限制：若表无主键，第一个 UNIQUE 索引会被 MySQL 自动当作主键处理，也无法设为不可见；第二个及之后的 UNIQUE 索引才可以
• 强制走索引也无效：即使写 SELECT * FROM t1 WHERE j = 10 FORCE INDEX(j_idx)，只要 j_idx 是不可见的，优化器仍会跳过它，不会报错也不会警告
• 临时启用靠会话级开关：需先执行 SET SESSION optimizer_switch = "use_invisible_indexes=on"，再跑 EXPLAIN 才能看到该索引被考虑；全局设置（GLOBAL）影响所有新连接，慎用

函数索引：让表达式也能走索引，但语法必须严格

MySQL 5.7 只能对列建索引，8.0 开始支持基于表达式的函数索引，比如 UPPER(name)、DATE(created_at)。但它不是“任意函数都行”，而是要求表达式可确定、无副作用、且必须用 GENERATED COLUMN 语义包装。

• 必须显式声明虚拟列：不能直接 CREATE INDEX idx ON t1(UPPER(name)) —— 这在 8.0 会报错 ERROR 3753 (HY000): Functional index column cannot be used directly in index definition。正确写法是先加生成列：ALTER TABLE t1 ADD COLUMN name_upper VARCHAR(255) GENERATED ALWAYS AS (UPPER(name)) STORED，再对 name_upper 建索引
• STORED 是硬性要求：函数索引只支持 STORED 类型的生成列，VIRTUAL 不行。因为索引需要物理存储值，而 VIRTUAL 列每次查询才计算，无法构建 B+ 树
• WHERE 条件必须完全匹配表达式：如果建的是 UPPER(name) 索引，查询必须写 WHERE UPPER(name) = 'JOHN' 才能命中；写成 WHERE name = 'john' 或 WHERE LOWER(name) = 'john' 都不会用该索引
• JSON 字段支持有限：可以对 JSON_EXTRACT(json_col, "$.field") 建函数索引，但仅限于提取标量值（string/number/boolean），不能对整个 JSON 对象或数组建索引

降序索引不是“锦上添花”，而是排序性能的关键开关

虽然标题没提降序索引，但它和不可见索引、函数索引同属 8.0 索引三大革新，且最容易被低估。它的价值不在“看起来更酷”，而在消除 Using filesort —— 尤其对分页、TOP-N 查询。

• 定义即生效，无需额外配置：CREATE INDEX idx ON t1(a ASC, b DESC) 在 8.0 中真实按降序组织 B+ 树节点；5.7 同样语句会被静默转为全升序，SHOW CREATE TABLE 里根本看不到 DESC
• ORDER BY 必须严格一致：索引是 (a ASC, b DESC)，那只有 ORDER BY a, b DESC 能免排序；换成 ORDER BY a DESC, b DESC 反而可能触发反向扫描（Backward index scan），性能不如 5.7
• 联合索引方向混合是常态：不要认为“全 ASC 最安全”。实际场景中，时间字段常需 DESC（最新优先），状态码常需 ASC（固定枚举），混合方向索引才是高频优化手段
• EXPLAIN 的 key_len 会暴露细节：当查询只用到前导列（如索引 (a ASC, b DESC)，查询 WHERE a = 1 ORDER BY b DESC），key_len 显示完整长度，说明走了索引排序；若出现 Using filesort，大概率是排序方向不匹配

真正难的不是语法，而是判断什么时候该用不可见索引做灰度、什么时候该用函数索引替代应用层转换、以及降序索引的方向是否和业务查询模式咬合。这三个特性都要求你对着 EXPLAIN 和真实慢查日志反复验证，而不是只看 DDL 是否执行成功。