MYSQL进阶：删除视图时视图被lock解决方案

背景

mysql 8.0 删除视图时 DROP VIEW dev_licos_kmlc_yt.view_pro_product_distribution_cathode_copper_details_v2 报错？ Waiting for table metadata lock

解决方案

你在 MySQL 8.0 中执行 DROP VIEW 时遇到 "Waiting for table metadata lock" 错误，说明该视图（或其依赖的表）当前被其他会话持有元数据锁（metadata lock），导致你的 DROP 操作被阻塞。

---

🔍 原因分析

在 MySQL 中，任何对表结构或视图的操作（如 DROP、ALTER、CREATE）都需要获取元数据锁（MDL） 。如果另一个会话正在：

• 执行一个长时间运行的查询（SELECT/INSERT/UPDATE/DELETE）涉及该视图或其基表；
• 开启了一个事务但未提交，并且事务中使用了该视图或相关表；
• 正在执行 DDL（如 ALTER TABLE）等操作；

那么你的 DROP VIEW 就会一直等待，直到那个会话释放锁。

注意：即使视图本身不包含数据，只要它引用的基表被锁定，DROP VIEW 也会被阻塞。

---

✅ 解决方法

1. 查找阻塞的会话

登录 MySQL，执行以下语句查看当前元数据锁等待情况：

SELECT * FROM performance_schema.metadata_locks 
WHERE OBJECT_SCHEMA = 'dev_licos_kmlc_yt' 
  AND OBJECT_NAME = 'view_pro_product_distribution_cathode_copper_details_v2';

或者更通用的方式：查看所有等待或持有 MDL 的线程：

SELECT 
    r.trx_id waiting_trx_id,
    r.trx_mysql_thread_id waiting_thread,
    r.trx_query waiting_query,
    b.trx_id blocking_trx_id,
    b.trx_mysql_thread_id blocking_thread,
    b.trx_query blocking_query
FROM 
    information_schema.innodb_lock_waits w
INNER JOIN 
    information_schema.innodb_trx b ON b.trx_id = w.blocking_trx_id
INNER JOIN 
    information_schema.innodb_trx r ON r.trx_id = w.requesting_trx_id;

⚠️ 注意：上面这个查的是 InnoDB 行锁，不一定适用于元数据锁。更准确的是用 performance_schema：

-- 启用 performance_schema（默认已启用）
SELECT 
    pl.processlist_id AS blocked_pid,
    pl.info AS blocked_sql,
    ml.lock_type,
    ml.lock_status,
    ml.owner_thread_id
FROM 
    performance_schema.metadata_locks ml
JOIN 
    performance_schema.threads t ON ml.owner_thread_id = t.thread_id
JOIN 
    information_schema.processlist pl ON t.processlist_id = pl.id
WHERE 
    ml.object_schema = 'dev_licos_kmlc_yt'
    AND ml.object_name = 'view_pro_product_distribution_cathode_copper_details_v2'
    AND ml.lock_status = 'PENDING';

也可以直接看谁持有该对象的锁：

SELECT 
    pl.id AS process_id,
    pl.user,
    pl.host,
    pl.db,
    pl.command,
    pl.time AS duration_seconds,
    pl.state,
    pl.info AS current_sql
FROM 
    performance_schema.metadata_locks ml
JOIN 
    performance_schema.threads t ON ml.owner_thread_id = t.thread_id
JOIN 
    information_schema.processlist pl ON t.processlist_id = pl.id
WHERE 
    ml.object_schema = 'dev_licos_kmlc_yt'
    AND ml.object_name = 'view_pro_product_distribution_cathode_copper_details_v2'
    AND ml.lock_status = 'GRANTED';

2. 终止阻塞的会话

找到阻塞的 process_id（即 pl.id），然后 kill 它：

KILL <process_id>;

例如：

KILL 12345;

⚠️ 谨慎操作！确保该会话可以被安全终止（比如是空闲连接、测试查询等）。

3. 预防措施

• 避免在业务高峰期执行 DDL（包括 DROP VIEW）。
• 确保应用中的事务及时提交，不要长时间开启事务。
• 对于只读查询，尽量使用短连接或设置 autocommit=1。
• 监控长时间运行的查询：SHOW PROCESSLIST;

---

💡 补充说明

• 视图本身不存储数据，但 MySQL 在 DROP VIEW 时仍需检查其定义和依赖关系，因此需要对基表加共享元数据锁。
• 即使视图未被直接使用，只要其基表被某个会话锁定，DROP VIEW 也可能被阻塞。

---

✅ 总结

你遇到的问题是典型的 元数据锁等待。解决步骤：

1. 使用 performance_schema.metadata_locks 找出谁持有了锁；
2. 通过 information_schema.processlist 找到对应会话 ID；
3. 必要时 KILL 阻塞会话；
4. 再次执行 DROP VIEW。

我使用的的是这个语句：

SELECT 
    pl.id AS process_id,
    pl.user,
    pl.host,
    pl.db,
    pl.command,
    pl.time AS duration_seconds,
    pl.state,
    pl.info AS current_sql
FROM 
    performance_schema.metadata_locks ml
JOIN 
    performance_schema.threads t ON ml.owner_thread_id = t.thread_id
JOIN 
    information_schema.processlist pl ON t.processlist_id = pl.id
WHERE 
    ml.object_schema = 'dev_licos_kmlc_yt'
    AND ml.object_name = 'view_pro_product_distribution_cathode_copper_details_v2'
    AND ml.lock_status = 'GRANTED';

然后查询出process_id，最终使用kill把阻塞会话杀掉，问题解决。