DynamoDB中如何避免EmailIndex GSI重复并支持用户名/邮箱登录

核心问题解答 #

你关于DynamoDB原生能力无法保障EmailIndex唯一的判断完全正确：

• DynamoDB的GSI本身是异步同步的最终一致性索引，没有任何原生的写入拦截、全局唯一约束能力。只要主表的写入满足自身PK/SK的约束（也就是用户名不同的两个注册请求），哪怕两个用户填写了完全相同的邮箱，主表写入会直接成功，同步到EmailIndex后就会生成两条键值重复的索引记录，完全没有办法在原生层面拦截。
• 哪怕在应用层先查一次EmailIndex再写入，也挡不住并发场景：因为GSI是最终一致的，两个并发请求可能都查不到已存在的邮箱记录，后续还是会双双写入主表生成重复数据。

官方推荐的通用实现方案 #

DynamoDB针对全局唯一性约束类需求，推荐的标准方案是独立唯一性辅助表 + 事务原子写入，完全可以在不强制单一登录标识的前提下，支持用户名/邮箱二选一登录，具体设计如下：

1. 设计专属唯一性辅助表 #

专门建一张用来存全局唯一标识的辅助表，表结构设计：

• 表主键（PK）：存储经过标准化处理的唯一标识（针对邮箱场景，存转换为小写、去除首尾空格的规范化邮箱，格式可设为uniq:email:<规范化邮箱地址>）
• 表排序键（SK）：对应用户的用户名/用户ID，用来和主表做关联
• 写入规则：所有对这张表的写入必须强制使用条件校验，仅当PK值不存在时才允许写入。

2. 用事务保障注册流程的原子性 #

用户注册的整个流程，不需要拆成多次独立请求，直接把所有写入操作放到TransactWriteItems事务中执行，事务内的写入逻辑为：

• 第一笔写入：向唯一性辅助表插入当前用户的邮箱记录，附带条件校验：当前规范化邮箱对应的PK不存在。如果校验失败（说明邮箱已被注册），整个事务直接回滚。
• 第二笔写入：向用户主表插入当前用户的用户名记录（PK为用户名），附带条件校验：当前用户名对应的PK不存在。如果校验失败（说明用户名已被占用），整个事务直接回滚。
  这种设计下，并发抢注同一个邮箱的场景会被从根源上解决：两个同时发起的同邮箱注册请求，只有一个能通过辅助表的条件写入校验，另一个会直接被事务拦截，根本不会产生重复的主表/索引记录。后续用户修改绑定邮箱时，同样可以把“旧邮箱的辅助表记录删除、新邮箱的辅助表记录插入、主表用户信息更新”三个操作打包到同一个事务里执行，全程保障邮箱的全局唯一。

3. 原有EmailIndex的定位调整 #

原来设计的EmailIndex不需要承担唯一性校验的职责，它只需要作为登录时的快速查询通道即可：因为通过辅助表的约束，所有写入主表的邮箱本身就是全局唯一的，同步到GSI的记录自然也不会出现重复。
用户登录时的逻辑也很简单：

• 如果用户输入的是用户名：直接查主表的PK获取用户信息即可
• 如果用户输入的是邮箱：先通过辅助表的强一致查询找到对应的对应用户ID/用户名，再回主表获取完整用户信息即可

关键注意事项 #

• 所有用于唯一约束的字段必须做规范化处理：比如邮箱统一转小写、去除首尾空格，避免因为大小写、不可见空格的差异，导致同一个真实邮箱被当成多个不同的键，让唯一性约束失效。
• 不要依赖GSI做存在性校验：GSI是最终一致性的，用它做前置查重会有明显的并发漏洞，所有涉及唯一性判断的校验，必须基于强一致的辅助表写入逻辑完成。
• 事务成本可控：注册是典型的低频写操作，使用DynamoDB事务带来的成本开销完全在可接受范围内，相比应用层加分布式锁、多次重试查重的方案，可靠性高得多，也是官方明确推荐的实现路径。

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