mysql 8.0升级后查询变慢主因是cost model默认启用但统计信息陈旧，导致优化器误判索引成本；需立即执行analyze table更新统计信息，并确认降序索引、函数索引等新特性是否被正确识别和使用。
Cost Model 默认启用，但依赖 ANALYZE TABLE；DESC 索引和函数索引在 8.0 才真正生效——5.7 只是语法通过、实际无效。
为什么升级后某些查询反而变慢了？
这不是 bug，而是 Cost Model 在“认真估算”但统计信息陈旧导致的误判。5.7 的优化器看到有索引就用，8.0 会对比 idx_a、idx_b、全表扫描的成本，选一个它认为最省的——但如果表没跑过 ANALYZE TABLE，它的“认为”就是错的。
- 执行
EXPLAIN FORMAT=TREE查看各节点预估cost，5.7 不支持该语法 - 检查是否启用：
SELECT @@optimizer_switch LIKE '%cost_model=on%' - 临时关闭调试用：
SET optimizer_switch='cost_model=off'，切回 5.7 式行为 - 大表务必在升级后立即执行一次
ANALYZE TABLE t1，后续建议每周定时执行
INDEX (a DESC, b ASC) 在 8.0 真能跳过 filesort 吗？
能，但条件苛刻：必须同时满足建索引时写了 DESC、查询中 ORDER BY 的字段顺序和方向完全一致、且 WHERE 条件覆盖最左前缀。
- 5.7 写
INDEX (a DESC, b ASC)会被悄悄忽略，SHOW CREATE TABLE显示仍是升序 - 8.0 物理级降序存储，
SELECT * FROM t WHERE a > 100 ORDER BY a DESC, b ASC可免filesort - 若写成
ORDER BY a DESC, b DESC而索引是(a DESC, b ASC)，不命中 -
ORDER BY a DESC LIMIT 10这类带LIMIT的也不能绕过间隙锁，别指望靠它“偷懒”
CREATE INDEX idx ON t ((UPPER(name))) 为什么在 5.7 报错？
5.7 解析器根本不认识双括号语法，直接抛 ERROR 1064；8.0.13+ 才真正支持，并底层映射为不可见虚拟列 + B+ 树索引。
- 只对确定性函数有效：
UPPER()、TRIM()可以，NOW()、RAND()不允许 - 查询条件必须与索引定义严格一致：
WHERE UPPER(name) = 'ABC'有效，WHERE UPPER(name) LIKE '%abc%'无效（B+ 树不支持前缀模糊） - 空格、大小写、括号嵌套层级都要一模一样，不是“语义等价”就算匹配
- 5.7 想实现类似效果只能靠冗余列 + 普通索引，应用层同步维护
隐藏索引 INVISIBLE 是性能优化功能吗？
不是。它是灰度验证工具，用来安全下线疑似无效索引，本身不提升性能，还多一份维护开销。
- 语法：
ALTER TABLE t1 ALTER INDEX idx_name INVISIBLE（5.7 不识别，报错） -
SHOW INDEX FROM t1中Visible列为NO即隐藏 - 隐藏后索引仍实时更新、占磁盘空间，只是优化器不选它
- 观察慢查是否复现：如果没变化，说明该索引大概率冗余；如果某条报表 SQL 突然变慢，赶紧
VISIBLE回来
容易被忽略的是：所有这些新能力都建立在准确统计信息基础上。没有 ANALYZE TABLE，Cost Model、降序索引、函数索引都可能“装聪明”，结果比 5.7 更糟。
