mysql 5.7主从同步中slave线程卡死，绝大多数情况是sql线程被锁、冲突或元数据等待阻塞，而非配置错误；stop slave可能也卡住，需先用pstack查锁竞争（如global_sid_lock）、show processlist找killing slave或waiting for table metadata lock状态，再针对性unlock tables或kill query。
MySQL 5.7 主从同步中 Slave 线程卡死，绝大多数情况不是配置错误，而是 SQL 线程被阻塞在锁、冲突或元数据等待上——直接 STOP SLAVE 可能也卡住，得先定位卡点再动手。
Slave_SQL_Running: No 且 show slave status 卡住，先查锁竞争
执行 show slave status\G 卡住，大概率是它和 show master status 或其他复制相关操作争抢 global_sid_lock 写锁。这不是数据问题，是命令执行时的并发锁冲突。
- 用
pstack <mysqld_pid></mysqld_pid>查线程栈，如果看到__lll_lock_wait和global_sid_lock->wrlock()，基本确认是锁阻塞 - 临时规避：停掉所有可能触发
show master status的监控脚本（比如某些 Zabbix 模板会定时轮询主从状态） - 不要在高负载或长事务期间频繁执行
show slave status，尤其避免和show master status并发执行 - MySQL 5.7.41+ 版本已优化该锁路径，但若无法升级，可考虑将 GTID 相关监控拆到专用只读账号下，减少锁争用
SQL 线程报错 1062（主键冲突）或 1032（找不到记录）
这类错误会让 Slave_SQL_Running 变为 No，且 Seconds_Behind_Master 停滞，Relay_Log_Pos 不再推进。
- 1062 错误常见于从库被误写：比如你在从库执行了
INSERT INTO test3 VALUES(1)，主库又写了同 ID 数据，回放时直接冲突 - 1032 错误多见于无主键表 + 并行复制：InnoDB 隐式
row_id主从不一致，导致 UPDATE/DELETE 找不到行 - 临时恢复可用
SET GLOBAL sql_slave_skip_counter = 1，但仅限紧急止血；跳过一次后务必START SLAVE并立刻SHOW SLAVE STATUS\G确认是否继续卡住 - 根本解法不是跳过，而是补主键：
ALTER TABLE test3 ADD id BIGINT AUTO_INCREMENT PRIMARY KEY FIRST（注意顺序和类型兼容性）
STOP SLAVE 自身卡在 Killing slave 状态
这说明 SQL 线程正持有某种资源（如表锁、MDL 锁），无法安全退出。最典型场景是从库上手动加了 LOCK TABLES ... READ，同时主库有新 binlog 到达。
- 执行
SHOW PROCESSLIST，找State为Waiting for table metadata lock或Killing slave的线程 - 检查是否有活跃的
LOCK TABLES操作（尤其是从库上人为执行的），执行UNLOCK TABLES后，卡住的STOP SLAVE通常立刻返回 - 更隐蔽的情况是长事务未提交：查
INFORMATION_SCHEMA.INNODB_TRX中trx_state = 'RUNNING'且COMMAND = 'Sleep'的记录，KILL QUERY <id></id>比直接KILL <id></id>更安全 - 避免在从库开启
read_only = OFF后不加管控，任何 DML 都可能埋下冲突或锁隐患
IO 线程卡在 Connecting 或 Waiting for master to send event
这不属于“SQL 线程卡死”，但常被误判为同一类问题。重点排查网络与权限链路。
-
Slave_IO_Running: Connecting90% 是连不上主库：用telnet <master_ip> 3306</master_ip>或nc -zv <master_ip> 3306</master_ip>实测端口通断，别只信 ping - 检查主库
GRANT权限是否针对从库 IP 精确授权，比如'slave'@'192.168.58.129'不能匹配'slave'@'%'（反向 DNS 或 host cache 可能干扰） - 从库
CHANGE MASTER TO中的MASTER_LOG_FILE和MASTER_LOG_POS必须严格对应主库SHOW MASTER STATUS输出，差一位都会卡住 - 防火墙、SELinux、云平台安全组都可能拦截 3306，别忽略中间链路设备
真正难处理的卡死，往往藏在“看起来正常”的细节里：比如一个没提交的 Sleep 事务霸着 MDL 锁，或者 global_sid_lock 被某个慢查询意外拖住。别急着跳过或重做，先用 SHOW PROCESSLIST 和 SHOW ENGINE INNODB STATUS\G 对着卡点看两分钟，比盲目重启快得多。
