MySQL 8.0索引调优三大改进：降序索引真正物理逆序存储并被优化器识别；函数索引支持UPPER等确定性表达式查询走索引；隐藏索引实现索引“软删除”与灰度验证。
MySQL 8.0 对索引调优的改进不是“锦上添花”，而是直接解决了长期困扰 DBA 和开发者的几个硬伤：降序索引终于真正生效、函数索引让表达式查询能走索引、隐藏索引让索引变更不再提心吊胆。
降序索引（DESC）在 ORDER BY 中真正起效
MySQL 5.7 虽然支持 INDEX(col DESC) 语法，但底层仍按升序构建 B+ 树，优化器也常忽略它；8.0 才是实打实的逆序物理存储 + 优化器识别。
- 适用场景：
SELECT * FROM orders WHERE status = 'paid' ORDER BY created_at DESC LIMIT 20—— 若有复合索引INDEX(status, created_at DESC)，Extra字段会显示Using index，无filesort - 注意点：
DESC必须显式写在CREATE INDEX语句中，仅靠ORDER BY ... DESC不会自动触发降序索引匹配 - 不兼容行为：若旧 SQL 依赖 5.7 的隐式升序行为（比如误以为
ORDER BY a DESC, b ASC能用INDEX(a,b)），升级后需重写索引或补全排序方向
函数索引（CREATE INDEX ... (UPPER(name))）让表达式查询可命中索引
以前 WHERE UPPER(name) = 'TOM' 必然全表扫描；现在可建函数索引，把计算结果固化进 B+ 树。
- 必须用括号包裹表达式：
CREATE INDEX idx_upper_name ON users ((UPPER(name)))—— 少一对括号会报错 - 仅支持确定性函数（如
UPPER、TRIM、JSON_EXTRACT），NOW()或RAND()等非确定性函数不允许 - 查询条件必须字面量一致：
UPPER(name)可用，但upper(name)（小写函数名）或UPPER( name )（空格差异）可能无法匹配（取决于 SQL mode）
隐藏索引（INVISIBLE）实现索引“软删除”与灰度验证
这是最安全的索引调优手段——索引仍在后台维护、数据实时更新，但优化器默认跳过它，相当于给索引加了个开关。
- 创建时即设为不可见：
CREATE INDEX idx_email_hash ON users (email) INVISIBLE - 运行时动态切换：
ALTER TABLE users ALTER INDEX idx_email_hash INVISIBLE/VISIBLE - 关键限制：主键和唯一约束相关的索引不能设为
INVISIBLE；全局临时表也不支持 - 验证是否生效：执行
EXPLAIN SELECT * FROM users WHERE email = 'a@b.com'，若key字段为空，说明隐藏成功
复合索引中混合升序/降序（INDEX(a ASC, b DESC)）提升多维度排序效率
当查询同时含多个排序方向（如分页场景 ORDER BY category ASC, score DESC），混合方向索引可避免二次排序。
- 必须严格匹配查询中的排序方向顺序：索引
(a ASC, b DESC)能用于ORDER BY a ASC, b DESC，但不能用于ORDER BY a DESC, b ASC - 若查询只用前缀列排序（如仅
ORDER BY a ASC），该索引仍可用；但若只用后缀列（如仅ORDER BY b DESC），则无法利用 -
GROUP BY同样受益：8.0 中GROUP BY a, b不再隐式排序，但若配合INDEX(a, b DESC)+ 显式ORDER BY a, b DESC，仍可免排序
真正容易被忽略的是：这些新索引类型都依赖优化器准确识别访问路径，而 ANALYZE TABLE 的统计信息质量直接影响判断。别只改索引，忘了定期更新统计信息——尤其在大表数据分布剧烈变化后。
