mysql主从复制中如何避免不必要的复制_数据同步优化-mysql教程-PHP中文网

不该同步的表包括tmp_、log_、cache_*等临时日志缓存表及performance_schema库，应使用replicate-wild-ignore-table按通配符过滤；大事务需拆分为小批量操作；gtid模式下跳过错误须用set gtid_next+空事务方式。

mysql主从复制中如何避免不必要的复制_数据同步优化

主从复制中哪些表不该同步

MySQL 主从复制默认同步所有库和表，但业务中常有临时表、日志表、缓存表（如 tmp_*、log_*、cache_*）或监控埋点表，它们写入频繁、无业务一致性要求，却会拖慢从库 IO 和 SQL 线程。这类表应主动排除。

推荐在从库配置 replicate-ignore-table 或更灵活的 replicate-wild-ignore-table：

replicate-wild-ignore-table = db_name.tmp_%<br>replicate-wild-ignore-table = db_name.log_%<br>replicate-wild-ignore-table = performance_schema.%

注意：replicate-ignore-table 不支持通配符，且必须写成 db.table 格式；而 replicate-wild-ignore-table 支持 % 和 _，更适合批量过滤。忽略规则只作用于从库的 SQL 线程，不阻止 binlog 记录，所以主库备份和 PITR 不受影响。

如何避免大事务导致从库延迟

单个事务写入数百万行（如历史数据归档、全量统计更新），会在从库重放时卡住 SQL 线程，造成秒级甚至小时级延迟。这不是网络或硬件问题，而是事务原子性强制的结果。

关键对策是「拆」——在主库侧控制事务粒度：

用 LIMIT + WHERE id > ? 分批更新，每批 1k–5k 行，配合 SLEEP(0.01) 避免锁竞争
禁用 AUTOCOMMIT=0 下的手动大事务；DDL 操作（如 ALTER TABLE）尽量用 pt-online-schema-change 或 MySQL 8.0+ 的 ALGORITHM=INSTANT
从库开启 slave_preserve_commit_order=ON（5.7+）可减少多线程回放时的内部等待，但前提是主库 binlog_order_commits=ON（默认）

过滤复制：用 replicate-do-db 还是 replicate-rewrite-db

replicate-do-db 看似直观，实则陷阱很多：它只检查 USE db_name 或语句中显式带库名（如 UPDATE db_name.t1），对跨库操作（UPDATE db1.t1 JOIN db2.t2）可能失效，极易漏同步。

MySQL（Linux）

MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。

下载

更可靠的方式是结合 replicate-wild-do-table 按表名过滤：

replicate-wild-do-table = app_db.%<br>replicate-wild-do-table = user_center.%

如果真需库名映射（比如主库用 prod_user，从库想存为 staging_user），才用 replicate-rewrite-db，但它仅重写语句中的库名前缀，不处理 CREATE DATABASE 或权限语句，且不能链式重写（两次 rewrite 无效）。

GTID 模式下跳过错误的正确姿势

遇到主从不一致报错（如 1062 Duplicate entry、1032 Can't find record），不要直接用 SET GLOBAL sql_slave_skip_counter=1 —— GTID 模式下该命令被禁用，强行执行会报错 ERROR 1794 (HY000)。

必须用 GTID 特有方式跳过：

查出当前停止位置的 GTID：SELECT @@global.gtid_executed; 和 SHOW SLAVE STATUS\G 中的 Retrieved_Gtid_Set、Executed_Gtid_Set
计算下一个要跳过的 GTID（例如 uuid:12345），然后执行：SET GTID_NEXT='uuid:12345'; BEGIN; COMMIT; SET GTID_NEXT='AUTOMATIC';
再 START SLAVE;。注意：跳过的 GTID 必须属于主库已生成但未在从库执行的范围，否则会破坏 GTID 集合一致性

这种操作本质是“伪造”一个空事务覆盖原位置，风险高，仅限紧急修复；长期方案仍是定位不一致根因（如从库被误写、主库未开启 log-slave-updates 导致级联中断）。