DynamoDB全局索引与本地索引对比：高效索引创建及选型指南

高效索引的通用创建原则 #

• 按需创建，避免过度索引：每个索引会增加写入开销（主表写入时需同步更新索引）和存储成本，只针对实际业务查询需求创建索引。
• 合理选择索引键：
  • 分区键：优先选择基数高的属性（如用户ID、商品ID），避免使用基数极低的属性（如状态值），防止热点分区导致性能瓶颈。
  • 排序键：如果需要范围查询（如按时间、金额筛选），选择适合排序的属性作为排序键，最大化索引的查询效率。
• 优化投影策略：
  • 优先使用KEYS_ONLY（仅投影主表和索引的键属性）或INCLUDE（指定需要的非键属性），减少索引存储体积和读取开销；仅当必须获取所有属性时才用ALL投影。
• 匹配读写模式：读多写少的场景可适当增加索引；写多的场景严格控制索引数量，避免写入性能被拖慢。

全局二级索引（GSI） vs 本地二级索引（LSI）：选择依据 #

优先选本地二级索引（LSI）的场景 #

• 查询范围限定在主表的单个分区键下，仅需要不同的排序键：比如主表以user_id为分区键、order_date为排序键，若要按order_amount范围查询某用户的所有订单，LSI刚好匹配（分区键与主表一致，排序键设为order_amount）。
• 需要强一致性读取：LSI支持强一致读，适合对数据实时性要求高的查询场景（GSI默认是最终一致读，开启强一致读会额外消耗RCU）。
• 主表是复合主键（分区键+排序键）：LSI要求主表必须为复合主键，这是前置条件。

优先选全局二级索引（GSI）的场景 #

• 需要跨主表分区键的查询：比如主表分区键是user_id，但业务需要按product_category查询全平台的相关订单，此时必须用GSI，将product_category设为GSI的分区键。
• 主表是简单主键（仅分区键）：LSI依赖主表的复合主键，这种情况下只能用GSI。
• 需要更多索引数量：每个主表最多支持5个LSI，但GSI默认支持20个（可申请提额），适合多维度查询的复杂业务。
• 读写模式与主表差异大：GSI可单独配置RCU和WCU，比如主表写多读少，但某个查询场景读极多，可给对应GSI单独调高RCU，不影响主表资源配置。

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