分表归并和数据迁移不是简单地把几张表“合起来”，关键在于业务逻辑一致性、历史数据完整性、以及迁移过程对线上服务的影响控制。
明确归并前提：哪些分表能合并？
并非所有分表都适合归并。需同时满足以下条件：
- 表结构完全一致（字段名、类型、约束、索引）；
- 分表依据是可逆的逻辑（如按时间、用户ID哈希、地区编码），且归并后主键/唯一键不冲突；
- 业务侧已下线旧的分表路由逻辑，统一走新单表或新分片规则；
- 存量数据无跨表外键依赖，或外键已转为逻辑关联（数据库外维护）。
归并操作三步走：导出–清洗–导入
避免直接 INSERT INTO ... SELECT 跨库大表拉取，易锁表、超时、OOM。推荐分批+校验方式：
- 分批次导出：按主键或时间范围切片（如 id BETWEEN 100000 AND 200000），用 mysqldump --where 或 pg_dump -t + WHERE 子句；
- 清洗去重与补全：检查并处理重复记录（如多张 user_2023、user_2024 表中存在相同 user_id 的脏数据）；补充缺失字段默认值或空值；
- 目标表批量写入：禁用目标表非必要索引和外键，用 LOAD DATA INFILE（MySQL）或 COPY（PostgreSQL）提升吞吐；完成后重建索引并校验行数、sum(md5(*)) 等聚合特征值。
迁移期间平滑过渡方案
不能停服？采用双写+回溯校验模式：
- 上线前开启“双写”：应用同时写原分表 + 新归并表（异步写新表可降低延迟）；
- 迁移历史数据时，用脚本从旧分表读取、转换、写入新表，按时间倒序优先迁移冷数据；
- 切流前执行最终一致性校验：对比新旧数据在关键字段（如金额、状态、更新时间）的差异，修复偏差；
- 切流后保留旧分表只读一段时间，用于问题回查，确认无误后再归档删除。
后续维护要点
归并不等于一劳永逸：
- 更新应用层所有涉及原分表名的 SQL、ORM 映射、报表查询、定时任务；
- 监控新表增长趋势，评估是否需重新分片（例如单表超 2000 万行或 10GB）；
- 将原分表策略文档归档，并在新表注释中说明归并来源及时间点，便于后续追溯。
