MySQL主从复制本身不自动保证强一致性，需结合配置、监控和运维手段来尽量减少数据差异。核心思路是：降低复制延迟、避免写入从库、及时发现并修复不一致。
启用半同步复制（Semi-sync Replication）
默认异步复制下，主库提交事务后不等待从库确认就返回成功，存在主库宕机而从库未收到日志的风险。半同步可强制至少一个从库写入 relay log 后，主库才提交。
主库安装插件：INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so';从库安装插件：
INSTALL PLUGIN rpl_semi_sync_slave SONAME 'semisync_slave.so';主库启用：
SET GLOBAL rpl_semi_sync_master_enabled = 1;从库启用：
SET GLOBAL rpl_semi_sync_slave_enabled = 1;（需重启 IO 线程生效） 建议搭配超时参数：
rpl_semi_sync_master_timeout = 10000（毫秒），避免主库长时间阻塞
校验与修复主从数据差异
即使复制正常，因语句级复制（STATEMENT）、非确定函数、跨库操作等，仍可能产生隐性不一致。需定期主动校验。
使用 pt-table-checksum（Percona Toolkit）在主库执行，生成校验和并同步到从库比对 校验前确保从库Seconds_Behind_Master = 0，且无长事务阻塞 发现不一致后，用 pt-table-sync 生成修复 SQL（建议先在测试环境验证） 避免直接在从库执行写操作；修复应通过主库变更或停写后重建从库
规避导致不一致的常见操作
很多“看似安全”的操作会悄悄破坏一致性，需在规范层面约束。
禁用SQL_LOG_BIN = 0在从库执行 DML —— 这类操作不记 binlog，主库无法感知，后续复制可能冲突 避免使用
NOW()、
UUID()、
USER()等非确定函数（ROW 格式可缓解，但仍建议用常量或应用层生成） 不要在从库创建临时表后执行依赖它的语句（临时表不复制，从库报错或跳过） DDL 操作（如
ALTER TABLE）需评估锁表时间，大表建议用 pt-online-schema-change 减少主从延迟激增
监控关键指标并设置告警
一致性是动态结果，靠人工检查不可持续。必须建立可观测性闭环。
核心指标：Seconds_Behind_Master（延迟秒数）、
Slave_SQL_Running和
Slave_IO_Running（是否为 Yes）、
Retrieved_Gtid_Set与
Executed_Gtid_Set是否一致（GTID 模式下） 延迟超过阈值（如 60 秒）需触发告警，并自动采样
SHOW PROCESSLIST和慢查询日志定位原因 建议用 Prometheus + mysqld_exporter + Grafana 可视化趋势，比单纯看数值更易发现抖动模式 每日定时跑 checksum，并将结果存档，便于回溯对比
