mysql 8.0 的 cost model 基于统计信息估算i/o与cpu成本以选择最优执行计划，但依赖定期analyze table更新统计信息；explain format=tree可查看预估cost值。
MySQL 8.0 的 Cost Model 让执行计划更“懂业务”
MySQL 5.7 的优化器基本靠固定规则选执行路径，比如“有索引就走索引”，但不会判断 WHERE a = ? AND b > ? 这种组合下用 idx_a 还是 idx_b 更快。MySQL 8.0 引入了 Cost Model，默认启用，它会基于统计信息估算不同访问路径的 I/O、CPU 成本，再选总代价更低的计划。
实际影响明显：复杂 JOIN 或多条件过滤时，8.0 更可能避开全表扫描，改用覆盖索引或更优的驱动表顺序。但前提是表统计信息准确——ANALYZE TABLE 要定期跑，否则 Cost Model 会“瞎估”。5.7 用户升级后如果没更新统计信息，反而可能看到执行计划变差。
- 检查是否启用：
SELECT @@optimizer_switch LIKE '%cost_model=on%'; - 强制关闭（仅调试用）：
SET optimizer_switch='cost_model=off'; - 8.0 中
EXPLAIN FORMAT=TREE可直接看到各节点预估 cost 值，5.7 不支持
InnoDB 聚簇索引和隐藏索引在 8.0 中的实际价值
MySQL 5.7 的聚簇索引结构没变，但 8.0 对其内部管理做了优化：页分裂更克制、二级索引回表时的主键查找路径更短。这在高并发写入场景（如订单号自增主键+高频插入）下，能减少锁竞争和 buffer pool 淘汰压力。
隐藏索引（ALTER TABLE t1 ALTER COLUMN c1 SET INVISIBLE;）不是性能提升功能，而是灰度验证工具。你可以把旧索引设为 INVISIBLE，观察慢查询是否复现，再决定是否删掉——避免“删错索引导致某条报表 SQL 突然变慢几秒”的生产事故。
- 隐藏索引仍占用磁盘空间和维护开销，只是不被优化器选中
-
SHOW INDEX FROM t1会显示Visible列，值为NO即隐藏 - 5.7 不识别
INVISIBLE语法，建表或修改会报错ERROR 1064
哈希索引只在 NDB Cluster 里真有用，InnoDB 的“哈希索引”是假的
文档里写的“MySQL 8.0 支持哈希索引”，容易让人误解成 InnoDB 表也能加 HASH 索引。实际上：NDB Cluster 存储引擎原生支持哈希索引；而 InnoDB 的“自适应哈希索引（AHI）”仍是 5.7 就有的机制，8.0 只是优化了它的触发阈值和内存管理逻辑。
AHI 是 InnoDB 自动在内存中为热点 B+ 树页构建的哈希映射，加速等值查询。但它不可控：你不能指定哪列建哈希、也不能关掉单个表的 AHI。而且一旦查询带范围（>、BETWEEN），AHI 就完全失效。
- 查 AHI 使用率：
SELECT * FROM information_schema.INNODB_METRICS WHERE NAME LIKE 'adaptive_hash%'; - 全局关闭 AHI（不推荐）：
SET GLOBAL innodb_adaptive_hash_index = OFF; - 5.7 和 8.0 的 AHI 行为差异极小，别把它当性能升级点来期待
临时表性能提升不是“变快了”，而是“少落盘了”
MySQL 5.7 中，只要临时表大小超过 tmp_table_size 和 max_heap_table_size 中的较小值，就会转成磁盘临时表（MyISAM 或 InnoDB），带来明显 I/O 开销。MySQL 8.0 把内存临时表的默认引擎换成了 TempTable，它是纯内存引擎，支持 BLOB/TEXT 字段且无大小硬限制（只受 innodb_temp_tablespaces_dir 空间约束）。
效果直观：含 GROUP BY + ORDER BY + 大字段的聚合查询，在 8.0 上更容易全程走内存，QPS 提升显著。但注意——如果 TempTable 内存耗尽，它仍会退化为磁盘表，此时性能反而比 5.7 更差（因为多了一层引擎切换开销）。
- 监控是否用了磁盘临时表：
SHOW GLOBAL STATUS LIKE 'Created_tmp_disk_tables'; - 8.0 中该指标下降 ≠ 性能一定好，得结合
Created_tmp_tables总量看比例 - 5.7 完全没有
TempTable引擎，所有超限临时表都强制落盘
真正卡住升级节奏的，往往不是执行引擎或索引这些“看得见”的改进，而是那些默认开关变了、统计信息不准、权限语句要拆成两步的细节。性能测试时，光比 TPS 没用，得抓着具体慢 SQL 看 EXPLAIN FORMAT=TREE 输出，再对比 information_schema.INNODB_METRICS 里的底层指标——否则很容易把配置失误当成版本缺陷。
