MySQL 8.0 升级后红黑树与性能优化无关，InnoDB 始终使用 B+Tree；MEMORY 引擎无结构性变化但上下文更严格；需重点关注 sql_mode、performance_schema 和 buffer_pool_size 三项行为变化。
MySQL 8.0 升级后红黑树和性能优化根本无关
MySQL 的 InnoDB 存储引擎从不使用红黑树作为主索引结构——无论 5.7 还是 8.0。它用的是 B+Tree，这是为磁盘 I/O 和范围查询深度优化的数据结构。红黑树在 MySQL 中只出现在极少数内部组件（比如某些内存管理链表或排序缓冲区的临时结构），但完全不参与用户表的索引构建、查询执行或执行计划生成。
如果你在升级后观察到“红黑树相关性能问题”，实际大概率是误读了文档、混淆了其他系统（如 Redis 或 C++ STL），或是被某些非官方教程误导。排查时请直接聚焦 EXPLAIN ANALYZE 输出中的 type、key、rows 字段，而不是搜索“红黑树”。
Memory 引擎没变，但升级后更危险了
MySQL 8.0 对 MEMORY 存储引擎本身没有结构性改动，但它运行的上下文变了：默认更严格的 sql_mode、更强的权限校验、以及 performance_schema 默认全开，会让原本“凑合能跑”的内存表暴露更多问题。
-
MEMORY表仍只支持HASH索引（不支持范围查询）和BTREE索引（需显式声明，但底层仍是 B+Tree 模拟，非原生支持） - 所有连接共享同一张内存表的锁：一次
UPDATE就会阻塞后续所有SELECT，并发写入场景下极易卡死 - 重启后数据清空逻辑未变，但 8.0 的
binlog复制机制对空表更敏感——备库重启后若没及时同步DELETE FROM t1清空语句，可能直接报 “no such row” 错误 -
max_heap_table_size和tmp_table_size仍共同限制单表大小，但 8.0 的临时表自动升级逻辑更激进，容易意外触发磁盘临时表（Using temporary; Using filesort）
真正该盯紧的三个升级后行为变化
别被“红黑树”带偏，MySQL 8.0 升级后影响内存表和查询性能的关键点就这三个：
-
sql_mode默认启用NO_ZERO_DATE和STRICT_TRANS_TABLES：原来能插入的'0000-00-00'现在直接报错，应用层没处理就会变成事务回滚 + 重试 + 锁等待，看起来像“内存表变慢”，实则是 SQL 被拦在解析/校验阶段 -
performance_schema默认全开：如果用了大量MEMORY表做中间计算，events_statements_history_long会持续采样每条语句，CPU 开销陡增，尤其在高频率INSERT ... SELECT场景下 -
innodb_buffer_pool_size配置沿用旧值：很多 DBA 把 5.7 的 2G 直接搬过去，结果 8.0 的 Buffer Pool 预热更重、分区更细，导致冷启动后前几分钟大量磁盘读，连带拖慢所有依赖临时表的流程
验证内存表是否真在拖慢你
别猜，用这几条命令快速定位：
查当前活跃的 MEMORY 表及其大小：SELECT table_schema, table_name, engine, round(((data_length + index_length) / 1024 / 1024), 2) AS mb FROM information_schema.tables WHERE engine = 'MEMORY' ORDER BY mb DESC;
看有没有因内存不足降级为磁盘临时表：SHOW GLOBAL STATUS LIKE 'Created_tmp%'; 关注 Created_tmp_disk_tables 是否突增
确认是否被 performance_schema 过度采集：SELECT * FROM performance_schema.setup_consumers WHERE NAME LIKE 'events_statements%' AND ENABLED = 'YES'; —— 生产环境建议关掉 events_statements_history_long
最常被忽略的是：升级后没人动过 tmp_table_size，但它和 max_heap_table_size 必须一致，否则内存表实际大小以二者中较小者为准——这个细节在 8.0 的错误日志里只报 warning，不中断服务，但会悄悄让表提前落盘。
