要验证 MySQL 主从复制是否正常工作，关键在于确认数据是否实时、准确地从主库同步到从库，并排除常见延迟或中断问题。下面介绍几种实用、可操作的验证方法。
检查复制线程状态
这是最基础也最重要的一步。登录从库执行：
SHOW SLAVE STATUS\G
重点关注以下字段：
Slave_IO_Running 和 Slave_SQL_Running 都应为 Yes，表示 I/O 线程和 SQL 线程都在运行 Seconds_Behind_Master 显示从库落后主库的秒数，理想值是 0（偶尔波动属正常，持续大于 0 需排查） IO_Relay_Log_Pos 和 Read_Master_Log_Pos 应随时间递增，若长期不变可能线程已卡住比对主从库数据一致性
仅看线程状态不够，还需验证实际数据是否一致。常用方式有：
在主库插入一条带唯一标识的测试记录（如INSERT INTO test_table VALUES (NOW(), 'verify_replication');），稍等几秒后在从库查询是否出现 对比主从库相同表的行数：
SELECT COUNT(*) FROM table_name;，尤其适用于小表或阶段性校验 对关键字段做校验和（如用
CRC32(CONCAT(col1,col2))或
MD5(GROUP_CONCAT(... ORDER BY id))），适合中等规模数据
查看主从 binlog 位置是否连续
主库写入靠 binlog，从库靠读取并重放这些日志。可通过位置点判断是否断点：
主库执行SHOW MASTER STATUS;，记下 File 和 Position 从库执行
SHOW SLAVE STATUS\G，查看 Master_Log_File 和 Read_Master_Log_Pos 二者应基本一致（允许短暂延迟），若 Master_Log_File 不同或 Read_Master_Log_Pos 停滞，说明 I/O 线程未拉取新日志
模拟写入并观察延迟变化
真实业务场景下，延迟可能随负载浮动。可主动施加压力验证稳定性：
在主库批量插入几百条记录，观察从库 Seconds_Behind_Master 是否先升高再回落至 0 使用pt-table-checksum（Percona Toolkit 工具）做全量一致性校验，适合生产环境定期巡检 开启从库的
log_slave_updates=ON后，还可将该从库作为二级主库，进一步验证 binlog 转发能力
