slave_sql_running: no 时应先查 last_sql_error 定位错误码（如1032、1062等），再结合 mysqlbinlog 解析具体sql；跳错优先用 sql_slave_skip_counter=1（sbr）或配置 slave_skip_errors（禁用 all）；权限变更须用 alter user 或手动同步并关闭 sql_log_bin。
主从复制中断：Slave_SQL_Running: No 怎么快速定位原因
看到 Slave_SQL_Running: No 不要急着跳过错误，先看 Last_SQL_Error——它直接告诉你 SQL 线程卡在哪条语句、哪个错误码。常见如 1032（找不到记录）、1062（主键冲突）、1418（函数创建不安全）、1050（表已存在）。这些错误背后逻辑不同，处理方式也完全不同：1032 往往说明从库数据缺失，硬跳可能放大不一致；1062 可能是主库重复插入，但更可能是从库残留了不该有的数据。
跳过错误的两种方式：SQL_SLAVE_SKIP_COUNTER vs slave_skip_errors
SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1 是临时跳过当前事务，适合单次偶发错误，比如一条误删导致的 1032；但它只对基于语句的复制（SBR）可靠，在默认的行格式（RBR）下可能跳过不完整事务，引发后续不一致。slave_skip_errors 是配置级跳过，写在 /etc/my.cnf 的 [mysqld] 下，例如：slave-skip-errors=1062,1032。注意：slave-skip-errors=all 极其危险，会掩盖主键冲突、数据丢失等严重问题，生产环境禁止使用。
用户权限变更引发复制失败：更新 mysql.user 表为什么从库会挂
直接 UPDATE mysql.user 修改用户 host 或密码，看似简单，实则高危。因为 mysql 系统库默认不参与复制过滤（除非显式配置 replicate-ignore-db=mysql），该语句会原样重放——但从库上执行时，若用户不存在或 host 不匹配，就会报错中断。更隐蔽的问题是：主库更新成功，从库因校验失败未执行，造成权限状态不一致，后续连接可能静默失败。正确做法是用 ALTER USER 命令（MySQL 5.7+），它被设计为复制安全；或者停掉 SQL 线程，在从库手动同步修改，并确保 sql_log_bin=0 避免二次写入 binlog。
解析 binlog 找真实操作：当 Last_SQL_Error 只显示位置不显示 SQL
尤其是 RBR 模式下，Last_SQL_Error 常只提示 Worker N failed executing transaction 'xxx' at master log mysql-bin.0000xx, end_log_pos 123456，看不到具体哪条语句出错。这时必须用 mysqlbinlog 解析：mysqlbinlog --base64-output=decode-rows -v --start-position=123400 --stop-position=123500 /var/lib/mysql/mysql-bin.0000xx > err.sql。重点看 ### UPDATE 或 ### DELETE 块里的 @1=... 参数，它们对应字段值；再比对从库对应表是否存在该主键记录。别依赖 show binlog events，它不展示行镜像内容。
最易被忽略的一点：复制异常往往不是孤立事件，而是上游某个误操作（比如没走应用层、直连主库改系统表）的滞后暴露。修复完 SQL 线程后，务必检查 Seconds_Behind_Master 是否归零，并用 pt-table-checksum 校验主从数据一致性——因为跳过或手动补数据，都可能只解决表面报错，不保证底层数据真正对齐。
