MySQL从库“system lock”实为SQL线程等待内部资源的假性状态，常见于MDL锁、行锁冲突、relay log I/O延迟等场景，并非操作系统级锁；需结合SHOW ENGINE INNODB STATUS和SECONDS IN WAIT综合判断是否真存在锁等待。
不是系统锁，是 SQL 线程被阻塞或 relay log 处理滞后导致的“假性 system lock”现象。 MySQL 从库 SHOW PROCESSLIST 中看到 system lock 状态，99% 不是操作系统级锁，而是 SQL 线程在等待某个内部资源（比如表元数据锁、行锁、或前一个事务未提交），它只是状态显示名，容易误导。
为什么 system lock 常被误认为是系统级锁
MySQL 的线程状态是语义化的，system lock 实际对应源码中 THD::ENTER_COND 阶段的等待入口，并不特指某类锁。常见触发场景包括：
- SQL 线程尝试获取
MDL（metadata lock）时被阻塞——例如主库刚执行了ALTER TABLE，从库回放时需加 MDL，但该表正被从库上另一个长事务持有读锁 - 回放 DML 时遇到行锁冲突——比如主库并行写入两行，但从库单线程回放，第二条 UPDATE 撞上了第一条尚未提交的事务持有的行锁
- relay log 切换或读取延迟——磁盘 I/O 慢、relay_log_space_limit 触发刷盘等待，线程卡在文件读取环节，状态暂显为
system lock - 从库开启了
binlog_format=STATEMENT且执行了非确定性函数（如NOW()、UUID()），SQL 线程可能因校验逻辑挂起
如何确认是不是真被锁住：看 SHOW ENGINE INNODB STATUS\G
这个命令输出里 TRANSACTIONS 和 LOCK WAIT 段落才是关键证据：
- 如果存在
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:，说明确有行锁/表锁等待，要结合TRX_ID和LOCK_TRX_ID查谁在 hold - 若只有
---TRANSACTION xxx, not started或大量ACTIVE但无 WAITING，大概率是 relay log 读取慢或 SQL 线程自身调度问题，和锁无关 - 注意检查
SECONDS IN WAIT字段——持续增长 > 60s 的 WAITING 才值得干预；瞬时出现又消失属正常调度抖动
Seconds_Behind_Master 为 0 但线程卡在 system lock 怎么办
这说明 IO 线程已拉完日志，但 SQL 线程无法推进。重点排查三类配置与行为：
- 确认是否启用了
slave_parallel_workers > 0：开启并行复制后，system lock更可能源于 coordinator 线程等待 worker 完成，而非传统锁；此时应查performance_schema.replication_applier_status_by_coordinator - 检查
innodb_lock_wait_timeout值：从库默认是 50 秒，若主库事务超时未提交，从库 SQL 线程会卡满 timeout 后报错退出（错误日志搜Lock wait timeout exceeded） - 禁用
autocommit=0的手动事务：从库 SQL 线程不支持长事务嵌套，任何显式BEGIN+ 长时间未COMMIT都会导致后续事件堆积在 relay log 中无法消费
真正棘手的是那些不报错、不超时、Seconds_Behind_Master 慢慢爬升、system lock 状态反复出现的情况——它往往藏在 relay log 解析阶段的隐式等待里，比如 GTID gap 清理、临时表重建、或字符集转换失败的静默重试。这时候得直接抓 mysqld 进程栈：pstack $(pgrep mysqld) 看线程卡在哪一行代码，而不是只盯状态字符串。
