mysql主从复制不支持分区表的独立复制控制，仅能按事务同步全部变更，无法实现按分区过滤或路由；需通过应用分片或代理中间件实现分区分流，原生复制仅支持库表级过滤。
MySQL主从复制本身不支持分区表的独立复制控制
MySQL的主从复制是基于二进制日志（binlog）的逻辑复制，它按事务粒度同步所有变更，CREATE TABLE ... PARTITION BY 语句和对分区表的 INSERT/UPDATE/DELETE 操作都会被完整记录并重放。这意味着：主库上对某个分区的操作，从库也会在对应结构的分区表上执行相同操作——但**没有机制让某个从库只同步特定分区、跳过其他分区，或把不同分区路由到不同从库**。
想实现“按分区分流”，必须绕开原生复制，改用应用层或中间件方案
常见可行路径有两类：
- 应用写入时根据分片键（如
user_id % 4）决定往哪个库写，再配合读请求路由——此时每个库实际是独立实例，不是传统意义的“主从”，而是分片（sharding）架构 - 使用代理层如
ProxySQL或MyCat，在 SQL 解析阶段识别PARTITION相关 hint 或条件（如WHERE tenant_id = 123），将请求转发到对应后端节点；但这要求后端节点数据已按分区逻辑预分配好，且复制链路需人工维护（比如用replication filters过滤库/表，但无法按分区过滤） - 若坚持用 MySQL 原生复制，唯一能做的粒度是
replicate-do-table或replicate-wild-do-table，仅支持库/表级过滤，对分区无效
分区表 + 主从复制的典型隐患
看似“自动分治”，实则容易埋坑：
- 主从延迟在分区表上可能更隐蔽：某一分区高频写入导致该分区所在 binlog event 积压，而其他分区看起来正常，监控难定位
-
ALTER TABLE ... REORGANIZE PARTITION是 DDL，会锁全表（即使只动一个分区），在大表上极易阻塞复制线程，引发从库Seconds_Behind_Master突增 - 从库如果因磁盘空间不足导致某个分区无法写入（如
innodb_file_per_table=ON下单个.ibd文件超限），整个复制会中断，错误信息类似Got error 168 from storage engine，而非明确提示“分区X失败” - 备份恢复时若未启用
--single-transaction或未注意FLUSH TABLES WITH READ LOCK对分区的影响，可能导致分区元数据与数据文件不一致
真正需要分区+分离查询负载？优先考虑归档或读写分离替代方案
例如：
- 冷热分离：用
ALTER TABLE ... EXCHANGE PARTITION把历史分区导出为独立表，再迁到专用归档库，主库只留热数据——归档库可停复制，不影响主业务 - 报表类查询走从库，但通过
read_only=ON+ 应用层标识（如 SQL 注释/*+ READ_FROM_SLAVE */）控制，而非依赖分区位置 - 分区字段和复制过滤字段不重合时（如按
created_at分区，但按tenant_id过滤复制），根本无法达成目标，硬做只会增加运维复杂度
分区表在主从环境里最稳妥的用法，其实是保持结构一致、不做特殊分流——它的价值在于本地查询裁剪（EXPLAIN PARTITIONS 显示只查某几个分区），而不是跨实例的数据分发逻辑。
