DynamoDB复合键表中条件表达式能否仅基于分区键做存在性校验

• DynamoDB 原生的attribute_exists()等所有条件表达式函数，仅会针对本次操作指定了完整复合主键的单条目标记录做校验，不会跨同分区下的其他记录做全局扫描检查。
• 你之前在Put Bug时配置的attribute_exists(PK)永远会命中，本质是你要写入的新Bug记录本身就会携带对应的PK值，这个条件检查的是新写入的这条记录自己有没有PK属性，和同分区下有没有对应用户完全无关，自然起不到防孤立数据的作用。
• DynamoDB 不存在“单条写操作时忽略排序键、仅校验同分区下存在某条PK对应记录”的原生语法，因为这种按分区键查所有行的逻辑属于Query操作范畴，本质是跨多行的范围扫描，不属于单条主键操作的条件校验能力。

你之前纠结的“忽略排序键校验同分区存在记录”的思路，本质是把校验逻辑想复杂了——按照你当前的表设计，每个用户记录的SK是和PK同值的固定规则，根本不需要扫描整个分区，直接定位到那一条确定的用户行做存在性检查，就能100%覆盖你要的校验需求。

用DynamoDB原生的原子事务就能实现强校验，不需要额外开发或加组件：

• 操作时使用TransactWriteItems事务，绑定两个原子操作：
  1. 第一步执行ConditionCheck动作：定位到对应用户的完整主键（PK为待关联用户对应的USER#X值，SK为和PK完全一致的USER#X值），设置校验条件：

     attribute_exists(PK) AND attribute_exists(SK) AND Type = :user_type
     

     将绑定参数:user_type设为表中用户记录的固定Type值即可
  2. 第二步执行原本的Put Bug记录操作
• 整个事务的原子性由DynamoDB保证：只要同分区下找不到符合规则的用户记录，整个事务会直接回滚失败，不会写入任何孤立的Bug数据，全程没有额外的并发竞态风险，也不需要手动预先调用一次Query或GetItem校验。

• 如果后续调整表结构，出现用户记录的SK不再和PK同值、没办法直接定位到用户完整主键的情况，不要靠单条Put的条件表达式硬扛，要么把用户主键的SK规则固定成可预测的固定值，要么在事务外先调用一次强一致的GetItem确认用户存在，再执行写操作，避免产生无效的孤立数据。
• 不要为了校验存在性对整个分区做Query操作：这种做法不仅会产生不必要的读容量成本，还可能因为最终一致性的问题，在高并发写入时出现校验漏判。

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