基于phone与email复合键的User表用户合并外键更新性能优化咨询

方案1：拆分用户主表与标识关联表 #

把原User表拆分为两个职责明确的表：

1. User_Master（用户主表）：仅存储全局唯一的master_id（用户主ID），这个ID一旦生成就永久不变，所有关联表都以它作为外键。
2. User_Identifier（用户标识表）：存储用户的各类标识（email、phone等），并关联对应的master_id。给email和phone分别添加非NULL唯一约束（允许字段为NULL，但非NULL时必须全局唯一）。

转换后的初始数据：
User_Master表：

User_Identifier表：

当新增email=a@gmail.com且phone=123的记录时：

• 检测到a@gmail.com关联master_id=2，123关联master_id=1，触发合并逻辑。
• 选择保留其中一个master_id（比如保留1），将User_Identifier中master_id=2的记录更新为master_id=1，同时补全该记录的phone字段为123（或新增完整标识记录后删除旧记录）。
• 所有关联表的外键都是固定不变的master_id，无需做任何更新。

方案2：原表新增"主用户ID"字段 #

不拆分表，在原User表中新增master_user_id字段，默认值等于自身的id，同时新增is_active字段标记记录是否有效：

合并用户1和2时：

• 新增用户3（email=a@gmail.com、phone=123），设置其master_user_id=3、is_active=true。
• 更新用户1和2的master_user_id=3、is_active=false，标记为已合并失效。
• 关联表查询时，通过master_user_id关联到有效用户；后续新增数据直接使用最新的master_user_id即可，历史关联数据无需修改。
• 可定期清理失效的用户记录，或保留用于数据溯源。

方案3：用组合标识作为外键（不推荐） #

若业务场景特殊，可直接用email+phone的组合作为关联表外键，但缺陷明显：

• 用户更新邮箱/手机号时，仍需批量更新外键，无法从根本解决性能问题。
• 无法处理仅含单个标识（仅邮箱或仅手机号）的用户关联场景，灵活性极差。

核心思路总结 #

所有方案的核心都是让关联表依赖一个稳定不变的用户标识，把用户合并的逻辑限制在用户专属表内，避免波及所有关联表。优先推荐方案1，它的职责划分更清晰，扩展性更强（后续新增微信ID、手机号等标识，直接在User_Identifier表加字段即可）。

内容的提问来源于stack exchange，提问作者Harshit Mahajan