DynamoDB带OR条件与ORDER BY查询报哈希键条件校验异常

这个报错是Amazon DynamoDB Query接口的硬性限制导致，核心问题出在索引选择和查询条件的匹配逻辑上：

1. 你指定使用的sender_company_id-created-index属于二级索引，其分区键（Hash Key）为sender_company_id，排序键（Sort Key）为created
2. DynamoDB单次Query操作只能查询单个分区键值对应的数据，要求WHERE子句必须包含目标索引分区键的等值匹配条件，且该条件不能被OR逻辑拆分为不满足约束的分支
3. 你写的OR条件第二个分支receiver_company_id = 435634652 AND receiver_user_id = 186，没有对当前索引的分区键sender_company_id做等值约束，相当于要求Query跨多个分区扫描数据。由于不同分区下的排序键是独立排序的，数据库无法直接基于现有索引完成跨分区的ORDER BY逻辑，因此触发校验错误。
4. 当你删除OR的第二个分支时，WHERE子句仅保留sender_company_id = 435634652这个符合要求的分区键等值条件，Query可以在单个分区内基于排序键直接返回有序结果，因此可以正常执行。

你当前使用的查询语句如下：

SELECT id, message, created, sender_company_id, receiver_company_id, read_msg, receiver_user_id, receiver_user_name, 
        sender_user_name, sender_user_id, sender_company_name, receiver_company_name
       FROM "messages"."sender_company_id-created-index"
       WHERE (sender_company_id = 435634652 AND sender_user_id = 186) 
       OR (receiver_company_id = 435634652 AND receiver_user_id = 186)
       ORDER BY created ASC, sender_company_id ASC

根据业务场景和数据规模，三选一即可：

• 方案1：双次查询+应用层归并（生产环境推荐）
  这是DynamoDB处理跨角色消息查询的标准实践，性能和成本最优：
  1. 保留现有sender_company_id-created-index索引，第一次查询匹配「我发送的消息」条件：sender_company_id = 435634652 AND sender_user_id = 186
  2. 新建一个分区键为receiver_company_id、排序键为created的二级索引（例：receiver_company_id-created-index），第二次查询匹配「我接收的消息」条件：receiver_company_id = 435634652 AND receiver_user_id = 186
  3. 两次查询的结果在应用层按created ASC、sender_company_id ASC的规则做归并排序，得到最终结果集。
• 方案2：全表Scan加过滤（仅适合小规模低频次场景）
  将Query操作改为Scan操作，保留现有OR过滤条件，最终排序在客户端完成。注意Scan会遍历全表所有数据，读容量消耗是Query的数十到数百倍，仅适合单表数据量低于10万、查询频率低于每天10次的场景，高频业务禁止使用。
• 方案3：表结构重构（适合长期迭代的业务）
  如果你的核心场景是查询单用户的所有收发消息、或者单聊会话消息，可以提前在写入消息时生成冗余字段：
  • 对单用户全量消息场景：新增message_owner_id字段，每条消息写入两行（一行owner是发送者，一行owner是接收者），创建以message_owner_id为分区键、created为排序键的索引，查询时直接按message_owner_id = 186过滤即可，不需要OR条件
  • 对单聊会话场景：新增session_id字段，将收发双方的ID按固定规则（小值在前大值在后）拼接为唯一会话ID，创建以session_id为分区键、created为排序键的索引，查询时直接按会话ID过滤即可，性能最高。

注意：不存在通过修改SQL写法、调整现有索引配置就让单次Query支持跨分区OR条件+ORDER BY的方案，这是DynamoDB的底层存储结构决定的，不要在这上面浪费时间。

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