MySQL：Slave_SQL_Running_State: System lock

你看到的 Slave_SQL_Running_State: System lock 出现在 SHOW SLAVE STATUS\G 的输出里，通常说明 SQL 线程在等待系统层级的锁。这是 MySQL 复制（传统 binlog replication）中比较常见的状态之一。下面我给你详细解释原因和对应解决思路：

---

📌 背景知识

在 MySQL 复制中：

• Slave_IO_Running 负责从主库拉取 binlog 并写到 relay log；
• Slave_SQL_Running 负责读取 relay log 并执行。
  Slave_SQL_Running_State 是 SQL 线程当前正在做的事情，比如：
• Reading event from the relay log
• Waiting for dependent transaction to commit
• System lock

---

📌 System lock 的含义

System lock 并不是表级锁或事务锁，而是 MySQL 在 应用 relay log 的 SQL 事件时，需要获取系统层面锁（metadata lock / 文件锁 / binlog dump 锁等），但此时被阻塞了。常见场景：

1. DDL 与复制冲突

   • 从库正在应用主库的 DDL（比如 ALTER TABLE），需要拿到 metadata lock，但本地有其他会话占用锁（例如正在执行 SELECT … FOR UPDATE）。

2. 大事务 / 长查询阻塞

   • 主库上执行了大事务，relay log 在应用时，SQL 线程需要锁定表结构，但本地有活跃连接持有 MDL（metadata lock）。

3. 备份 / 工具冲突

   • 你在从库上跑了 mysqldump --single-transaction、pt-online-schema-change 或其他会持有 metadata lock 的工具，SQL 线程就卡住了。

---

📌 如何确认问题

在从库执行：

SHOW PROCESSLIST\G

看一下 Slave_SQL 线程的状态，以及是否有其他线程正在等待或持有锁。

也可以用：

SHOW ENGINE INNODB STATUS\G

查看是否存在 metadata lock 争用。

MySQL 5.7+ 还可以查：

SELECT * FROM performance_schema.metadata_locks\G

确认是谁占用了 metadata lock。

---

📌 解决方案

1. 立即处理阻塞

   • 找到阻塞 Slave_SQL 的会话（一般是 metadata lock），如果允许，可以 KILL <thread_id>。

2. 避免 DDL 与复制冲突

   • 在主库做 DDL 前，评估是否能用 pt-online-schema-change 或 MySQL 8 的 ALGORITHM=INPLACE/INSTANT。
   • 从库尽量避免长事务或占用 metadata lock 的会话。

3. 拆解大事务

   • 如果主库经常有大事务，可以调整业务逻辑，把事务拆小，减少从库复制压力。

4. 监控与预防

   • 建立对 Slave_SQL_Running_State 的监控，如果长时间停留在 System lock，要告警。
   • 优化备份方式，避免与复制线程抢锁。

---

✅ 总结：
Slave_SQL_Running_State: System lock 说明 SQL 线程在等待系统级锁，大概率是元数据锁（MDL）阻塞。
排查思路是：先看 SHOW PROCESSLIST / performance_schema.metadata_locks 找阻塞来源 → 结束阻塞会话 → 优化 DDL 和备份流程避免再次发生。

要不要我帮你写一份 快速排查 SQL 线程卡在 System lock 的诊断 SQL 脚本？