视图查询变慢通常源于底层执行计划变化而非视图本身；需用explain展开视图定义分析type、key、rows、extra等字段，重点关注performance_schema依赖、union/嵌套子查询及条件无法下推三类8.0高频问题，并优先考虑直查基表或物化替代。
视图查询变慢，大概率不是视图本身的问题
MySQL 8.0 中视图（VIEW）本身不存储数据，只是保存了 SELECT 语句的定义。所谓“视图变慢”，本质是底层查询执行计划变了——尤其是当视图依赖 information_schema 或 performance_schema 表时，升级后行为差异会直接暴露出来。比如 sys.innodb_lock_waits 在 5.7 和 8.0 中分别查 information_schema.innodb_lock_waits 和 performance_schema.data_lock_waits，后者在高并发锁等待场景下可能触发更重的元数据扫描或行级锁竞争。
用 EXPLAIN 看清视图背后的真执行计划
对视图直接跑 EXPLAIN SELECT * FROM my_view 只能看到“临时表”或“derived”这类模糊提示，无法穿透到底层表。必须展开视图定义，把 SELECT 子句原样贴出来再 EXPLAIN：
EXPLAIN SELECT w.* FROM performance_schema.data_lock_waits w JOIN information_schema.INNODB_TRX b ON b.trx_id = w.BLOCKING_ENGINE_TRANSACTION_ID ...;
重点关注几个字段：
-
type：如果出现ALL或index，说明没走有效索引；ref或eq_ref才算健康 -
key：显示实际使用的索引名，为空表示未命中 -
rows：预估扫描行数，若远超结果集大小（比如查 10 行却扫 10 万行），就是典型瓶颈 -
Extra：含Using temporary或Using filesort是性能杀手，尤其在performance_schema表上几乎不可接受
MySQL 8.0 视图慢的三个高频坑
不是所有视图都平等。以下三类在 8.0 升级后最容易出问题：
- 依赖
performance_schema的监控类视图（如sys.innodb_lock_waits、sys.statements_with_full_table_scans）：这些表底层是内存映射结构，但 8.0 加强了事务可见性检查，导致扫描开销翻倍 - 含
UNION或多层嵌套子查询的视图：优化器在 8.0 中默认启用derived_merge=ON，有时反而让本可下推的条件失效，手动加/*+ NO_MERGE() */提示能强制走老路径 - 查询条件无法下推到基表的视图：比如视图定义为
SELECT a, b FROM t WHERE c > 10，但外部查询又加了AND d = 5，而d不在视图列里——此时 MySQL 8.0 可能放弃下推，先全量物化再过滤
绕过视图、直查基表往往是最有效的“优化”
如果你确认某视图只是用于监控或诊断（比如定时脚本查锁），别纠结“怎么优化视图”，直接换写法：
- 用
SELECT ... FROM performance_schema.data_locks替代sys.innodb_lock_waits，跳过中间 JOIN - 把视图里的
WHERE条件提前，避免让优化器猜——比如原视图定义含WHERE status = 'ACTIVE'，外部再WHERE user = 'app'，不如合并成单条SELECT ... FROM t WHERE status = 'ACTIVE' AND user = 'app' - 对高频调用的视图，考虑用物化方式替代：建一张
CREATE TABLE lock_summary AS SELECT ...并定期REPLACE INTO刷新，比实时查视图快一个数量级
真正难处理的，是那些你无法修改 SQL 调用方（比如第三方监控工具硬编码了 SELECT * FROM sys.xxx）又不能关掉的视图。这时候得盯住 performance_schema.setup_consumers，关掉不用的消费者（如 events_statements_history_long），减少底层采集压力——视图慢，有时只是因为底下的数据太“胖”了。
