mysql 8.0升级后视图关联查询变慢主因是优化器默认启用derived_merge=on和hash_join=off，导致条件无法下推、join退化为全表扫描或临时表物化，尤其在performance_schema视图上引发锁竞争与数据量激增。
MySQL 8.0升级后视图关联查询变慢，大概率不是视图写法问题，而是底层执行计划被优化器“误优化”了——特别是当视图含JOIN、子查询或依赖performance_schema时，derived_merge=ON和hash_join=off这类默认开关变化会直接让原本走索引的路径退化成全表扫描或临时表物化。
为什么EXPLAIN看视图只会显示“derived”而看不出真问题
对视图直接跑EXPLAIN SELECT * FROM my_view，MySQL 8.0 只会返回type=derived、key=NULL这种笼统提示，根本看不到JOIN是否走索引、WHERE条件有没有下推。这是因为视图在执行阶段才展开SQL，EXPLAIN无法穿透。
- 必须手动展开视图定义：用
SHOW CREATE VIEW my_view拿到原始SELECT语句，把整个子查询贴出来再跑EXPLAIN - 重点盯
type字段：如果从ref变成ALL，说明索引失效；rows值暴涨10倍以上就是典型信号 -
Extra里出现Using temporary或Using filesort，尤其在performance_schema表上，基本等于性能已崩
视图JOIN变慢的两个关键optimizer_switch开关
MySQL 8.0 默认启用了更激进的派生表合并策略，但对复杂视图反而有害。以下两个开关最常引发关联查询劣化：
-
derived_merge=ON：会让优化器强行把子查询“合并”进外层JOIN，结果导致本可下推的WHERE条件失效，先全量物化再过滤 -
hash_join=off：8.0 引入哈希连接本是利好，但默认关闭；老SQL若靠嵌套循环硬扛，新版没开哈希连接，JOIN性能反而倒退 - 验证方式：
SET SESSION optimizer_switch='derived_merge=off,hash_join=on';后再EXPLAIN，观察type和rows是否回归正常
performance_schema视图JOIN卡死的真实原因
像sys.innodb_lock_waits这类监控视图，在8.0中底层从information_schema.innodb_lock_waits切到了performance_schema.data_lock_waits，但后者记录的是“所有事务持有的锁”，而非5.7中仅“阻塞其他事务的锁”。数据量可能差几个数量级。
- 一个大事务锁住300万行，
data_lock_waits就生成300万条记录 - 每次查询该视图都要全表扫描+持有
trx_sys->mutex，阻塞所有新事务启动 - 解决方案不是调优，而是绕过：直接查基表
information_schema.INNODB_TRX+INNODB_LOCKS（5.7兼容路径），或改用sys.schema_table_statistics等轻量视图
视图里有UNION或嵌套子查询时怎么避免物化膨胀
MySQL 8.0 对UNION ALL的物化更保守，但对含ORDER BY/LIMIT的子查询，默认仍会强制物化为临时表。一旦外层JOIN再引用这个临时表，就触发二次扫描。
- 加优化器提示强制不合并：
SELECT /*+ NO_MERGE(tmp) */ ... FROM (SELECT ... FROM t ORDER BY id LIMIT 100000) AS tmp JOIN ... - 确保子查询的
ORDER BY字段有覆盖索引，否则Using filesort会先于JOIN发生 - 避免在视图里写
SELECT *，字段越多，物化临时表的内存开销越大；明确列出所需字段能显著减少中间结果集体积
真正棘手的点在于：这些性能退化往往不报错、不告警，只表现为慢查询缓慢爬升。最容易被忽略的是performance_schema类视图的锁竞争本质——它不是SQL写得差，而是读元数据的动作本身成了全局瓶颈。
