seconds_behind_master不准是因为它只反映i/o与sql线程时间差，不包含事务执行耗时；真正应监控主从位点（如exec_master_log_pos）或gtid集合差。
主从复制延迟大时，SHOW SLAVE STATUS 的 Seconds_Behind_Master 为什么经常不准
这个值只反映 SQL 线程和 I/O 线程之间的时间差，不包含事务实际执行耗时。比如主库刚提交一个大事务（如 ALTER TABLE），从库还在解析 relay log，Seconds_Behind_Master 可能仍显示 0，但数据已实质落后。
真正要预警的是「主从位点差异」而非时间差。推荐用 SELECT MASTER_POS_WAIT() 或对比 Exec_Master_Log_Pos 和主库的 File/Position —— 这两个值才是可比的物理位置。
- 监控脚本里别只查
Seconds_Behind_Master > 60，要同时检查Slave_IO_Running == Yes且Slave_SQL_Running == Yes，否则延迟值无意义 - 高并发写入下，
Seconds_Behind_Master会剧烈抖动，建议采样周期 ≥ 30 秒，取中位数而非瞬时值 - GTID 模式下优先用
Retrieved_Gtid_Set和Executed_Gtid_Set做集合差，比文件+位置更可靠
主从表结构不一致导致同步中断后，slave_exec_mode=IDEMPOTENT 能不能直接开
不能。这个参数只对主键/唯一键冲突有效（比如重复插入相同 PRIMARY KEY），对列缺失、类型不匹配、默认值变更等 DDL 不兼容问题完全无效，强行开启只会掩盖错误，让 SQL_THREAD 跳过报错继续执行，最终导致数据静默不一致。
真实场景中，90% 的结构不一致都源于未在从库执行 ALTER TABLE，或执行顺序与主库不一致（例如先删索引再加字段）。
- 发现
ERROR 1032 (HY000)或ERROR 1054 (42S22)同步中断，第一反应不是改slave_exec_mode，而是立刻停掉STOP SLAVE，然后用pt-table-checksum扫描差异 -
slave_exec_mode=IDEMPOTENT仅适用于已知可控的幂等写入场景（如日志表批量导入），上线前必须在测试环境验证所有 DML 是否真能跳过而不丢数据 - MySQL 8.0.26+ 支持
replica_parallel_workers > 0时自动检测并跳过部分冲突，但依赖transaction_write_set_extraction=XXHASH64，旧版本不生效
用 pt-table-checksum 做主从一致性校验，为什么经常卡在 wait_timeout
工具默认用长连接逐块校验，如果从库 wait_timeout 设置过短（比如 60 秒），连接会在校验中途被服务端断开，表现为 Lost connection to MySQL server during query，后续块重试失败，校验停滞。
这不是网络问题，是连接生命周期和校验耗时不匹配。尤其当表有大文本字段、无合适索引分块、或从库负载高时，单块校验可能耗时数分钟。
- 运行前先在从库执行
SET SESSION wait_timeout = 28800（8 小时），或永久修改配置文件中的wait_timeout，注意不要影响其他应用连接 - 避免在校验期间执行
FLUSH TABLES WITH READ LOCK，这会让pt-table-checksum等待全局锁，加剧超时风险 - 对超大表（>10GB），用
--chunk-size手动调小分块（如--chunk-size=1000），配合--chunk-index指定覆盖索引，减少单块扫描行数
从库误写入导致主从数据不一致，INSERT ... ON DUPLICATE KEY UPDATE 能否回填修复
不能。这类语句在从库执行时，如果主键存在，会触发 UPDATE 分支，但更新内容来自从库当前行值，而非主库原始值 —— 相当于用错误数据覆盖错误数据，越修越偏。
典型误操作是运维人员连错从库执行了写入，此时从库某行的 updated_at 变成新时间，而主库仍是旧值；若用 ON DUPLICATE KEY UPDATE 回填，会把从库的“错误新时间”当成正确值写回去。
- 修复必须基于主库快照：用
mysqldump --single-transaction --where="id IN (...)"导出主库目标行，再导入从库（注意禁用 binlog：SET SQL_LOG_BIN = 0） - 如果误写入量大，优先考虑重建从库：用
innobackupex备份主库，apply-log后恢复到从库，比逐行修复更可靠 - 预防比修复重要：从库务必设置
read_only = ON，并确认super_read_only = ON（MySQL 5.7.20+），普通账号即使有UPDATE权限也无法写入
主从差异预警不是靠某个开关或命令就能一劳永逸，关键在把位点比对、结构校验、连接生命周期、权限控制这几件事拆开盯死。漏掉任何一环，报警就只是个安慰剂。
