在Amazon DynamoDB中，PutItemRequest结合ConditionExpression是执行条件写入操作的强大工具。开发者常希望利用这一机制来确保特定属性的全局唯一性，尤其当这些属性作为全局二级索引（GSI）的一部分时。然而，对于GSI属性的全局唯一性检查，ConditionExpression的行为可能与直觉不符，导致意外的写入成功。
理解ConditionExpression与GSI唯一性
问题中提到的代码片段如下：
var req = PutItemRequest.builder()
.tableName(TABLE_NAME)
.item(getAllValues(settings))
.conditionExpression("attribute_not_exists(#" + MAC_ADDRESS + ") AND attribute_not_exists(#" + REGISTRATION_CODE + ")")
.expressionAttributeNames(Map.of("#" + MAC_ADDRESS, MAC_ADDRESS, "#" + REGISTRATION_CODE, REGISTRATION_CODE))
.build();这里的核心误解在于attribute_not_exists(attribute_name)条件表达式的作用范围。当在PutItemRequest中使用此条件时，它主要用于以下两种场景：
- 防止覆盖现有项： 如果attribute_name是表的主键（分区键或复合主键），则条件表示“只有当主键对应的项不存在时才执行写入”。这是最常见的防止重复创建项的方法。
- 检查当前写入项的属性是否存在： 如果attribute_name是待写入项中的一个普通属性，则条件表示“只有当待写入的这个项中不包含名为attribute_name的属性时才执行写入”。
关键点在于： attribute_not_exists条件表达式不会扫描整个表或GSI来检查MAC_ADDRESS或REGISTRATION_CODE的值是否已存在于其他**项中。它只针对当前正在处理的PutItemRequest所涉及的项进行评估。
在上述示例中，如果getAllValues(settings)返回的item中包含了MAC_ADDRESS和REGISTRATION_CODE这两个属性，那么attribute_not_exists(#MAC_ADDRESS)和attribute_not_exists(#REGISTRATION_CODE)将评估为false，因为这些属性在待写入的项中是存在的。因此，无论这些MAC地址或注册码是否已存在于其他项中，条件表达式都将失败，导致PutItem操作无条件成功（除非主键冲突）。
全局二级索引（GSI）的主要目的是提供灵活的查询能力，允许您使用与主键不同的属性集来访问数据。它们本身不强制执行全局唯一性约束。即使您在GSI中定义了某个属性作为分区键，DynamoDB也允许GSI中的分区键值在不同的GSI项中重复出现，只要它们属于不同的主表项即可。
模拟GSI唯一性约束的复杂性
虽然DynamoDB本身不直接支持GSI的全局唯一性约束，但可以通过更复杂的机制来模拟。AWS官方博客曾介绍过一种使用DynamoDB事务（Transactions）来模拟唯一性约束的方法。
基本思路：
- 创建“影子”表或唯一性检查表： 为需要唯一性的属性（例如MAC_ADDRESS）创建一个单独的表，或者在主表中为每个需要唯一性的属性创建一个特殊的“唯一性检查项”。
-
事务性写入： 使用TransactWriteItems操作，在一个事务中同时执行两个写入：
- 将实际数据写入主表。
- 将一个包含唯一属性值（例如MAC_ADDRESS作为主键）的项写入“影子”表或唯一性检查项。此写入操作会附带attribute_not_exists条件，确保该唯一属性值在“影子”表中是首次出现。
- 原子性保证： 如果“影子”表的写入因唯一性冲突而失败（即attribute_not_exists条件不满足），整个事务将回滚，主表的写入也不会发生。
注意事项：
- 开销增加： 事务操作会引入额外的请求单位（RCU/WCU）开销，因为需要执行多次写入操作。
- 复杂性增加： 这种方法需要额外的表设计和更复杂的应用逻辑来管理事务。
- 性能考量： 对于高吞吐量的场景，频繁的事务操作可能会对性能产生影响。
最佳实践：重新思考表结构设计
鉴于模拟GSI唯一性约束的复杂性和开销，更推荐的方法是重新评估和优化您的DynamoDB表结构设计。
如果MAC_ADDRESS或REGISTRATION_CODE在您的应用中是必须全局唯一的标识符，那么最自然和高效的方式是：
-
将其作为主表的主键：
- 分区键： 如果MAC_ADDRESS本身足以唯一标识一个项，可以考虑将其作为主表的分区键（Partition Key）。DynamoDB强制分区键的唯一性，确保不会有两个项具有相同的分区键。
- 复合主键： 如果需要结合其他属性来唯一标识，可以将其作为复合主键（Partition Key + Sort Key）的一部分。例如，MAC_ADDRESS作为分区键，DEVICE_ID作为排序键。
示例：将MAC_ADDRESS设为主表分区键 假设您的表主键是MAC_ADDRESS。那么，当您尝试插入一个新项时，可以使用以下PutItemRequest来防止重复：
var req = PutItemRequest.builder() .tableName(TABLE_NAME) .item(getAllValues(settings)) .conditionExpression("attribute_not_exists(MAC_ADDRESS)") // 假设MAC_ADDRESS是主键 .build();这里的attribute_not_exists(MAC_ADDRESS)会检查是否存在相同MAC_ADDRESS的项。如果存在，操作将失败，从而实现唯一性。
应用层预检查： 对于非主键的属性，如果唯一性要求不那么严格，或者性能要求极高，可以在写入前在应用层进行一次Query或GetItem操作来检查该值是否已存在。如果存在则拒绝写入。但这会引入竞态条件，不适用于强一致性要求。
总结
在DynamoDB中，PutItemRequest的ConditionExpression主要用于基于主键或当前写入项的属性进行条件判断，它无法直接在全局二级索引（GSI）上强制执行全局唯一性。当您需要确保某个属性的全局唯一性时，应优先考虑将其作为主表主键的一部分。如果这不可行，且强唯一性是强制要求，那么采用基于事务的复杂方案可以模拟实现，但需要权衡其带来的开销和复杂性。理解ConditionExpression的实际作用范围，并结合DynamoDB的特性进行合理的表结构设计，是构建高效、健壮应用程序的关键。
