方案概览与核心原理
为何要进行表级复制
在企业数据库场景中，MySQL 主从复制可以将写入压力分担到从节点，并为报表、离线分析等场景提供实时数据。当业务只关注部分表时，完整复制会带来资源浪费和延迟，因此需要实现仅同步部分表的表级复制。
通过在从库侧配置复制过滤规则，可确保仅把指定表的变更应用到从节点，从而实现粒度可控的数据订正与分发，降低带宽和存储压力。
表级复制与数据一致性考量
表级复制需要谨慎处理外键、触发器以及跨表的事务边界，因为从库并不需要复制主库的全部语义，因此在设计时要确保依赖关系清晰。
在多数场景下，ROW-based 日志格式能提供更稳定的增量变更记录，避免由于语句级的差异导致的重复或缺失更新。
实现路径与配置要点
基于从库的过滤配置
核心思路是在从库端通过复制过滤规则来限制哪些表需要接收日志。通过配置 replicate-do-table、replicate-wild-do-table 与对照数据库名，可以实现精确控制哪些表被同步。
需要注意的是，在使用 GTID 模式时，过滤规则仍需要与主从的事务定位一致，以确保从库能正确应用日志位置。
基线数据与增量同步的组合
在正式开启复制前，建议先在主库对目标表进行一次基线快照，以确保从库有一个一致的起点。常见做法是使用 mysqldump 针对指定表导出数据，并在从库导入完成后再开启复制。
mysqldump -h master_host -u repl_user -p --single-transaction --tables db_target.table1 db_target.table2 > baseline.sql
导入基线后，使用 CHANGE MASTER TO 设置主从关系，并确保从库缓存中的 relay log 与主日志位置对齐，以保证增量变更的连续性。
CHANGE MASTER TOMASTER_HOST='master_host',MASTER_USER='repl_user',MASTER_PASSWORD='password',MASTER_LOG_FILE='mysql-bin.000001',MASTER_LOG_POS=107;
实操步骤与示例
准备工作与环境要求
确保主从服务器的版本兼容，以及网络连通性稳定性。为表级复制准备的关键点包括 正确设置 server-id、开启二进制日志，以及在从库端配置相应的过滤条件。
建议在从库上启用 read_only，以避免误操作影响复制流程，确保数据的一致性。
逐步配置与验证
第一步，在从库的配置文件中添加过滤规则，目标表示例为 db_target.table1 与 db_target.table2。
[mysqld]
server-id = 2
log_bin = mysql-bin
relay_log = mysql-relay-bin
read_only = 1replicate-do-table = db_target.table1
replicate-do-table = db_target.table2
第二步，重新启动从库服务，并执行 CHANGE MASTER TO 指向主库的相应位置，随后执行 START SLAVE。
CHANGE MASTER TOMASTER_HOST='master_host',MASTER_USER='repl_user',MASTER_PASSWORD='password',MASTER_LOG_FILE='mysql-bin.000001',MASTER_LOG_POS=107;START SLAVE;
第三步，监控从库的复制状态，检查 Slave_IO_Running 与 Slave_SQL_Running，确保双方处于 YES 状态，若有错误则定位到特定表的日志。
数据一致性校验与故障处理
在初次基线完成后，应定期进行 行级对比 或使用校验和工具确认主从数据一致性。
mysql -h master_host -u checks -p -e "CHECK TABLE db_target.table1, db_target.table2"
遇到日志不一致、表结构变更等情况时，暂停复制并重新评估过滤规则，避免将来继续出现偏差。
常见问题与排查
常见问题清单
在部分表的表级复制场景中，常见的问题包括 漏同步、重复应用、以及依赖表未同步导致的约束失败。
为避免这些问题，建议保持 过滤规则的简单化，并确保变更不会影响未被同步的表的外键和触发器逻辑。
跨数据库与命名冲突的处理
如果从库需要接收不同数据库中的表，务必通过 全限定名 指定过滤器，确保 命名冲突最小化，并在变更完成后进行准确的对比。
数据丢失风险与回滚策略
在开启表级复制前，应设计一个明确的 回滚计划，包括基线快照的可回滚性，以及在必要时如何停止复制并回滚到某个一致点。
