视图查询会触发元数据锁等待，因为mysql执行视图时需为每个基表加共享mdl锁，若任一基表正被alter等ddl持有排他mdl锁，所有视图查询即排队等待。
视图本身不持有元数据锁（MDL），高频访问下出现的 Waiting for table metadata lock 问题，几乎总是由视图依赖的基表被其他 DDL 操作阻塞所致——比如有人在改 orders 表结构，而此时大量查询正通过 order_summary_view 执行，就会卡在 MDL 等待上。
为什么视图查询会触发元数据锁等待
MySQL 在执行视图时，需先解析其定义并校验所有基表的结构有效性，这个过程会为每个基表加共享 MDL 锁（MDL_SHARED_READ）。只要有一个基表正被 ALTER、DROP 或 TRUNCATE 等 DDL 持有排他 MDL 锁（MDL_EXCLUSIVE），所有试图访问该视图的查询就会排队等待。
常见诱因包括：
- 运维在业务高峰期执行
ALTER TABLE users ADD COLUMN last_login_at DATETIME - 监控脚本每分钟调用
SELECT COUNT(*) FROM customer_view，而该视图 JOIN 了 5 张表，任意一张被 DDL 就全堵住 - ORM 自动迁移工具未加锁控制，在应用发布时并发触发多个 DDL
如何避免视图引发的 MDL 阻塞链
核心思路是：不让 DDL 和视图查询在时间/对象上正面冲突。这不是索引或事务优化能解决的问题，而是架构层的隔离设计。
实操建议：
- 禁止在业务高峰时段执行任何涉及视图基表的 DDL；可结合
pt-online-schema-change或gh-ost替换原生ALTER，它们不阻塞 SELECT - 对高频视图所依赖的表，提前做「DDL 归组」：把常一起变更的表（如
orders、order_items）纳入同一维护窗口，减少锁竞争频次 - 用
SHOW PROCESSLIST定期抓取长时间处于Waiting for table metadata lock状态的线程，定位具体阻塞源表（Info列为空、State列为该值的线程，其db和Command可辅助判断） - 对只读报表类视图，考虑迁移到从库执行；主库只承担写入和关键读，物理隔开 DDL 影响面
哪些视图更容易放大 MDL 风险
不是所有视图都一样危险。以下特征会显著提高被卡概率：
- 定义中包含 3 张及以上基表的
JOIN（每多一张表，就多一个 MDL 获取点，任一失败即整体阻塞） - 嵌套视图：如
v1基于t1，v2基于v1，则查v2实际要锁t1+v1元数据，层级越深风险越隐蔽 - 使用了
UNION ALL或子查询的复杂视图，MySQL 解析时需临时展开，MDL 持有时间略长于简单视图 - 视图名带业务前缀但实际跨库引用（如
reporting.sales_summary查询core.orders），跨库 DDL 更难协调
真正麻烦的从来不是“怎么让视图快”，而是“怎么让它别在别人改表时突然全体失联”。MDL 冲突往往发生在最意想不到的时刻——比如凌晨三点自动备份脚本顺手 OPTIMIZE TABLE 了一张小表，结果导致整个订单看板接口超时。盯住 DDL 的节奏，比优化视图 SQL 重要十倍。
