SQL线程卡死是MySQL 8.0主从延迟最常见根因，需通过Slave_SQL_Running_State（如Waiting for table metadata lock、Updating超30秒）和持续增长的Time值（如120→600）综合判断，而非仅看Slave_SQL_Running: Yes；因8.0默认LOGICAL_CLOCK并行模式下，大事务内部仍强制串行回放，极易导致“假活”。
SQL线程卡死是MySQL 8.0主从延迟最常见、也最容易误判的故障点——它常表现为Seconds_Behind_Master持续上涨，但Slave_SQL_Running仍显示Yes，让人误以为“还在跑”，实际早已被锁住或陷入单一大事务回放。
怎么看SQL线程是不是真卡住了
别信SHOW SLAVE STATUS\G里那行Slave_SQL_Running: Yes。关键要看Slave_SQL_Running_State和Time字段：
-
State长期停在Waiting for table metadata lock、Waiting for commit lock或Updating（且持续超30秒）→ 基本就是MDL锁或大事务堵死 -
Time值持续增长（比如从120升到300再升到600），而State不变 → SQL线程没卡在等待，是在执行一个超长操作，极大概率是单条UPDATE/DELETE扫了百万行 -
Relay_Master_Log_File和Exec_Master_Log_Pos长时间不动 → 日志位置冻结，不是网络问题，是SQL线程彻底没推进
为什么8.0里SQL线程更容易“假活”
MySQL 8.0默认启用slave_parallel_type = LOGICAL_CLOCK，但并行只作用于不同事务之间；同一个事务内部仍强制串行回放。一旦主库提交了一个未拆分的大事务（比如UPDATE orders SET status=2 WHERE created_at ），从库SQL线程就会全程单线程扛下来，期间无法处理后续任何事件。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 即使开了
slave_parallel_workers = 16，对这个事务也完全无效 -
SHOW PROCESSLIST里看不到多个Worker在跑，只看到一个system user线程在Updating - 这种卡死不会报错，
Last_SQL_Error为空，Seconds_Behind_Master照常跳涨
查大事务和锁的实操命令
登录从库，立刻执行这三条命令，顺序不能错：
-
SELECT * FROM INFORMATION_SCHEMA.INNODB_TRX\G→ 找trx_state = 'RUNNING'且trx_rows_modified > 100000的事务；重点看trx_started时间是否远早于当前时间 -
SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCK_WAITS\G→ 如果有记录，说明SQL线程正等锁，配合INNODB_TRX里的trx_id能定位到谁在阻塞它 -
SHOW ENGINE INNODB STATUS\G→ 拉到最后的TRANSACTIONS部分，看是否有lock struct(s)和waiting for this lock to be granted字样
临时缓解但别跳过的动作
发现卡死后，先别急着STOP SLAVE或SET GLOBAL slave_skip_errors。优先确认是否可安全中断：
- 如果卡在
Waiting for table metadata lock，去主库查SHOW PROCESSLIST，找对应表的ALTER或DROP语句，等它结束比强行中断更稳妥 - 如果卡在
Updating且trx_rows_modified超200万，确认该事务是否业务允许中断（比如非核心报表导入），再考虑KILL掉SQL线程后START SLAVE让其重试 - 所有操作前，务必用
SELECT MASTER_POS_WAIT('mysql-bin.000xxx', 123456789)确认主库当前位置，避免跳过不该跳的日志
真正难的从来不是发现卡死，而是判断那个正在执行的事务，到底能不能停、停了会不会丢数据、停完之后要不要人工补数据——这些决策依据，全藏在INNODB_TRX的trx_query和trx_operation_state里，而不是Seconds_Behind_Master那个数字里。
