seconds_behind_master持续>300需立即止损：先stop slave sql_thread确认是否卡住，再根据卡点（ddl/大事务）选择跳过或调参；启用logical_clock并行回放并检查gtid断层；延迟恢复后须用pt-table-checksum校验数据一致性。
从库 Seconds_Behind_Master 持续 > 300 怎么快速止损
延迟不是“等一等”就能好的，尤其是当 Seconds_Behind_Master 超过 5 分钟，说明从库已积压大量 relay log，单纯重启 SQL 线程或跳过错误大概率失败。优先做两件事：确认是否真卡住，再决定是“清积压”还是“换同步方式”。
常见错误现象：SHOW SLAVE STATUS\G 中 Slave_SQL_Running_State 长时间停在 Reading event from the relay log 或 Waiting for dependent transaction to commit；Relay_Log_Space 持续上涨但 Exec_Master_Log_Pos 几乎不动。
- 先执行
STOP SLAVE SQL_THREAD，避免边查边写导致状态混乱 - 用
mysqlbinlog --base64-output=decode-rows -v查看最新 relay log 里最后几条事件，确认是否卡在某个 DDL（比如ALTER TABLE）或大事务上 - 若卡在 DDL，且主库已执行完成，可考虑跳过（
SET GLOBAL sql_slave_skip_counter = 1），但仅限单条语句、无主键变更场景；否则必须人工补数据
主库大事务导致从库重放慢怎么调参数
MySQL 默认串行回放，一个 2GB 的 INSERT ... SELECT 在从库可能跑 20 分钟，而主库只花了 3 秒——这不是网络或磁盘问题，是并行策略没打开。
使用场景：MySQL 5.7+，主库 binlog_format = ROW，且业务写入以多库/多表为主（非单表高频更新）
- 必须开启
slave_parallel_type = LOGICAL_CLOCK（不能用 DATABASE，兼容性差） - 调高
slave_parallel_workers到 4~8（别盲目设 16+，线程争抢反而降速） - 确认主库已开启
binlog_transaction_dependency_tracking = WRITESET（5.7.22+），否则从库无法按 writeset 并行 - 注意：如果主库大量使用
UNICODE函数或触发器，writeset 可能失效，退回到 COMMIT 时间戳模式，效果打折扣
MASTER_AUTO_POSITION=1 开启后从库还是报 Could not execute Write_rows_v1 event
这是 GTID 模式下典型的“事件缺失”错误，不是数据损坏，而是从库 relay log 里某条事务找不到对应的 binlog 文件位置，常见于主库 purged 了旧 binlog，但从库还没来得及拉取。
根本原因：主库 expire_logs_days 设太小（比如 1），而从库延迟超过 1 天，主库自动清理了它还没消费的 binlog。
- 立刻检查主库
SHOW MASTER LOGS和从库Retrieved_Gtid_Set的最大 GTID，看是否断层 - 若断层，
RESET SLAVE+ 手动CHANGE MASTER TO ... GTID_SET = 'xxx'指向主库当前Executed_Gtid_Set是唯一安全做法 - 禁止用
SET GTID_NEXT+ 空事务跳过——会破坏 GTID 连续性，后续切换主从可能失败 - 长期方案：主库把
expire_logs_days改成 7~14，且监控gtid_purged变化频率
从库延迟恢复后如何验证数据一致性
别信 Seconds_Behind_Master: 0，它只表示 relay log 消费完了，不代表数据和主库一致。尤其经历过跳过、重设、并行回放的从库，checksum 结果可能错位。
关键点：pt-table-checksum 不适合大表在线校验（锁表+全表扫描），但它是目前最可靠的逻辑层比对工具。
- 先在从库执行
SELECT COUNT(*)和CHECKSUM TABLE对几个核心表抽样，和主库结果比对 - 用
pt-table-checksum --replicate=test.checksums --no-check-binlog-format（跳过 binlog 格式检查，避免误判） - 若发现不一致，用
pt-table-sync --sync-to-master生成修复 SQL，**务必先在测试库回放验证**，再上生产 - 注意：该工具依赖主从时间同步（NTP），时钟偏差 > 1 秒会导致 checksum 表记录错乱
最易被忽略的是：主库有 innodb_autoinc_lock_mode = 0（传统模式）时，并行插入的自增 ID 在从库可能顺序不同，但数据内容一致——这种“假不一致”需要人工识别，不能直接同步。
