mysql 8.0索引三大实质性升级是不可见索引、函数索引和降序索引：不可见索引支持软删除与灰度发布但主键不可设为不可见；函数索引需基于stored生成列且where必须严格匹配表达式；降序索引可消除filesort但order by方向须与索引定义完全一致。
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 是否执行成功。
