MySQL下保留全部约束的5GB单库拆分迁移至多租户数据库方案咨询

5GB体量的数据库属于中小规模迁移范畴，全量迁移可将停机窗口控制在分钟级，不需要引入重型分布式分片组件，核心目标是100%保留原有的主键、外键、唯一索引、CHECK约束、触发器等原生数据库约束，避免因多租户改造丢失原有业务规则校验。

适配约束保留要求的多租户架构选型 #

不同多租户模式的约束改造成本、完整度差异很大，可根据租户规模、隔离要求选择匹配的方案：

• 共享库共享表模式（全局tenant_id标识）：约束改造成本最低，适合百级以内租户规模的场景。核心改造点是将原有的单字段唯一约束调整为租户维度的联合唯一约束——比如原表基于email字段建立的唯一索引uk_user_email，改造为(tenant_id, email)的联合唯一索引，完全匹配原有业务的唯一性校验逻辑；外键仅需在所有关联表统一带上tenant_id字段做逻辑对齐，不需要调整原外键的核心关联规则。
• 共享库独立Schema模式：约束完整度最高，相当于同一MySQL实例下为每个租户单独分配一套独立的表结构，原库的所有约束定义可以原封不动复用，不需要做任何索引、外键的逻辑改造。适合租户规模在十到几十级、租户间有合规隔离要求的场景，5GB的总数据量拆分后对MySQL实例的性能影响几乎可以忽略。
• 大租户独立实例模式：针对租户体量大、需要资源硬隔离的场景，迁移本质是单库搬迁，所有数据库约束完全不需要调整，可直接复用原库结构。

注意：不要选择完全在应用层做租户隔离、数据库层不保留约束校验的方案，这类方案无法满足“完整保留所有数据库约束”的核心要求。

零约束丢失的迁移落地步骤 #

• 前置结构校验
  先在测试环境1:1复刻原库结构，逐表梳理导出所有约束清单（主键、外键、唯一索引、CHECK约束、触发器的完整定义）留底，作为迁移完成后的比对基准。如果选择共享表模式，提前完成所有结构调整：给每张业务表添加同主键类型的tenant_id字段（INT/BIGINT即可），将所有单字段唯一索引改造为带租户维度的联合索引，提前在测试环境跑通所有结构调整脚本，确保调整后的约束逻辑和原规则完全一致。
• 数据迁移顺序控制（规避外键依赖报错）
  因为要保留外键约束，不能无序导入数据，否则会触发父表数据缺失的外键报错：
  1. 迁移会话临时关闭外键检查：SET FOREIGN_KEY_CHECKS = 0;
  2. 按照原库的外键依赖关系，按“父表优先、子表靠后”的顺序导入数据，所有历史数据统一映射到默认租户ID
  3. 全量数据导入完成后，重新开启外键检查，逐表运行CHECK TABLE <表名> FOR UPGRADE;，校验外键一致性、唯一约束是否存在冲突
• 切换前的一致性校验
  全量数据导入后不要直接切生产流量，需完成两轮校验：
  • 结构diff：逐表比对新老库的表结构、约束定义，确认所有原约束都已存在，共享表模式下的联合唯一索引逻辑和原唯一约束的业务规则完全匹配
  • 数据量核对：逐表统计新老库的记录数，确认无数据丢失
  • 约束触发测试：使用原业务场景中会触发约束报错的测试用例（比如重复插入唯一键值、插入不符合外键关联规则的记录、插入不满足CHECK约束的非法值），确认新库的报错逻辑和原库完全一致

迁移过程中需要避开的常见坑 #

• 不要为了压缩迁移时长，提前删掉原库的外键、触发器约束，等数据导完再手动补建。这种操作很容易漏配约束，最好是先完成所有新结构、约束的建设，再导入数据。
• 共享表模式下，千万不要遗漏唯一索引的改造。如果保留原单字段唯一索引，不同租户的重复业务字段（比如不同租户用户使用相同注册邮箱）会直接触发唯一键报错，破坏租户隔离逻辑。
• 5GB体量的库不需要引入额外的分布式迁移中间件，直接使用MySQL自带的mysqldump、LOAD DATA命令即可完成迁移，速度足够快，还能避免第三方工具导致的约束定义丢失问题。

内容的提问来源于stack exchange，提问作者Pavan Elthepu