验证MySQL主从复制正常工作的核心方法包括：检查SHOW SLAVE STATUS中Slave_IO_Running和Slave_SQL_Running均为Yes、Seconds_Behind_Master接近0；插入测试数据比对主从一致性；核对主库SHOW MASTER STATUS与从库Master_Log_File及Read_Master_Log_Pos是否连续；通过批量写入观察延迟变化，并可用pt-table-checksum定期校验。
要验证 MySQL 主从复制是否正常工作，关键在于确认数据是否实时、准确地从主库同步到从库，并排除常见延迟或中断问题。下面介绍几种实用、可操作的验证方法。
检查复制线程状态
这是最基础也最重要的一步。登录从库执行：
SHOW SLAVE STATUS\G
重点关注以下字段：
win可用的mysql指令skill
下载
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
- 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 转发能力
