不能信。Seconds_Behind_Master为NULL通常表示SQL线程已停止，而非追上主库；只要Slave_SQL_Running: No，数据就大概率不一致，须优先检查Slave_SQL_Running_State和Last_SQL_Error。
主从同步报错后，SHOW SLAVE STATUS 显示 Seconds_Behind_Master: NULL 还能信吗？
不能信。这个值为 NULL 通常意味着 SQL 线程已停止，不是“追上了”，而是“卡死了”。只要 Slave_SQL_Running: No，无论 Seconds_Behind_Master 显示什么，数据都大概率已不一致——因为从库连重放 binlog 都停了。
- 停止的直接原因是 SQL 线程遇到无法自动跳过的错误（如重复键、缺失表、类型不匹配）
-
Seconds_Behind_Master依赖 SQL 线程持续运行才能计算，一停就失效 - 不要依赖它判断一致性，必须先看
Slave_SQL_Running_State和Last_SQL_Error
用 pt-table-checksum 做校验前，必须绕开的三个权限与配置坑
pt-table-checksum 不是“装完就能跑”，它对主从环境很敏感，常见失败根本不是工具问题，而是权限或配置没到位：
- 主库必须开启
binlog_format = STATEMENT或MIXED（ROW模式下 checksum 结果无法被从库正确重放，导致校验永远不一致） - 执行用户需具备：
REPLICATION CLIENT、PROCESS、SELECT（所有待校验库表）、INSERT/UPDATE（在percona.checksums表操作） - 从库不能设置
read_only = 1（否则pt-table-checksum写入校验结果失败，报错Table 'percona.checksums' is read only）
pt-table-sync 同步时，为什么越修越乱？关键在 --sync-to-master 和 --dry-run
pt-table-sync 默认不连接主库，它只基于从库当前数据反推“应该执行哪些 SQL”——如果主从结构复杂（比如级联从库、多源复制），它很容易搞错方向。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 必须显式加
--sync-to-master，强制它以主库为唯一真相源，生成“从主库往从库修”的语句 - 永远先跑
--dry-run --print：它会输出将要执行的REPLACE或DELETE，逐条核对是否合理（比如是否误删主库有、从库没有的行） - 切忌在从库上直接
--execute：应把--print输出保存成 SQL 文件，在从库上用mysql手动导入，并加SET SQL_LOG_BIN = 0避免写入自身 binlog
真正深度对齐：跳过 checksum 的“假一致”，直查主从 binlog 位点与 GTID
有些场景下 pt-table-checksum 显示“0 行不一致”，但业务仍出错——因为校验只比对最终数据快照，漏掉了中间状态（如主库上刚插入又删除，从库因延迟还没来得及删）。
- 先确认主从是否启用 GTID：
SELECT @@gtid_mode;，启用后看Executed_Gtid_Set是否完全包含Retrieved_Gtid_Set - 若未启用 GTID，对比主库
SHOW MASTER STATUS的File/Position和从库Relay_Master_Log_File/Exec_Master_Log_Pos，二者必须严格相等才算“物理位置对齐” - 位点一致 ≠ 数据一致（比如主库执行了
DROP TABLE，从库还没来得及执行），此时必须结合业务逻辑判断：该表是否已被弃用？是否有替代同步机制？
修复不一致从来不是“一键同步”能解决的事。最危险的操作，是看到 Seconds_Behind_Master: 0 就以为万事大吉——那个 0，可能只是 SQL 线程恰好停在一条安全语句之后，而下一条就是毁灭性冲突。
