不能直接用mysqldump做实时同步，因其为快照导出、会锁表或产生一致性读开销，存在延迟且无法持续捕获变更；实时同步须依赖binlog流式复制。
为什么不能直接用 mysqldump 做“实时同步”
因为 mysqldump 是快照式导出，执行时会锁表（或至少产生一致性读开销），导出再导入的过程存在明显延迟，且无法持续捕获后续变更。所谓“实时同步”，本质是基于 MySQL 的主从复制机制，依赖 binlog 流式传输事件，不是文件搬运。
确认本地库已开启并正确配置 binlog
这是前提，否则测试环境连第一个事件都收不到。检查项必须逐条验证：
-
SHOW VARIABLES LIKE 'log_bin';返回ON，不是空值或OFF -
SHOW VARIABLES LIKE 'binlog_format';推荐设为ROW（语句级STATEMENT在函数、时间戳等场景下易导致从库不一致） -
SHOW VARIABLES LIKE 'server_id';必须是非 0 唯一整数（例如1），本地和测试环境不能相同 - 确认
my.cnf中有log-bin = mysql-bin和server-id = 1，且重启过 MySQL
在测试环境执行 CHANGE MASTER TO 指向本地开发库
测试环境作为从库，需明确知道主库（即你的本地机器）的连接信息和 binlog 起始位置。关键点：
- 本地执行
SHOW MASTER STATUS;，记下File（如mysql-bin.000003）和Position（如154） - 测试环境执行前，确保已创建用于复制的专用用户：
CREATE USER 'repl'@'%' IDENTIFIED BY 'strong_pass'; GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%'; -
CHANGE MASTER TO必须包含完整参数：MASTER_HOST='192.168.x.x'（本地真实 IP，非localhost或127.0.0.1）、MASTER_USER='repl'、MASTER_PASSWORD='strong_pass'、MASTER_LOG_FILE='mysql-bin.000003'、MASTER_LOG_POS=154 - 启动复制：
START SLAVE;，然后立刻用SHOW SLAVE STATUS\G查看Slave_IO_Running和Slave_SQL_Running是否均为Yes
常见同步中断原因与快速定位方法
一旦 Seconds_Behind_Master 持续增长，或两个 Running 状态变 No，优先查这几处：
-
Last_IO_Error：网络不通、权限拒绝、主库 binlog 被删（如purge binary logs过早）、主从server_id冲突 -
Last_SQL_Error：从库已有同名表但结构不同、主库执行了DROP DATABASE而从库不存在该库、触发器或存储过程不兼容 - 本地开发库若频繁重启，
binlog文件序号会重置（除非配置max_binlog_size=0并禁用自动轮转），导致从库找不到下一个文件 - 测试环境磁盘满、临时表空间不足，也会静默卡住 SQL 线程
真正麻烦的是 ROW 格式下主从数据不一致却无报错——此时 SHOW SLAVE STATUS 看不出异常，但业务查不到新数据。务必在同步启动后，立即比对几张核心表的 COUNT(*) 和几条随机记录的 UPDATE_TIME。
