为何在DynamoDB中使用CONTAINS扫描GSI速度未达预期？

为什么GSI扫描和原表扫描速度差异不大？ #

你当前用contains做过滤条件，不管扫原表还是GSI，本质都是全表扫描后再过滤数据。原因很明确：

• DynamoDB只有Query操作能利用GSI的HASH/RANGE键缩小查询范围，而contains属于后置过滤条件，是扫描完所有数据后才执行的筛选逻辑。
• 你的GSI以name为HASH键，但contains是模糊匹配，没法通过HASH键的精确匹配特性减少扫描条目数，所以扫描GSI和原表的条目总量一致，调用次数和速度自然差异不大。

为什么GSI的IndexSizeBytes和ItemCount与原表一致？ #

• ItemCount一致：这是正常情况。只要原表条目存在name属性，就会在GSI中生成对应条目，所以GSI的ItemCount和原表保持同步（如果原表有部分条目无name属性，GSI的ItemCount会更少）。
• IndexSizeBytes接近原表：虽然GSI是KEYS_ONLY投影，但它存储的是GSI主键（name）加上原表主键（Id）。如果你的name字段本身长度较长，加上Id的存储体积，单条GSI条目的大小和原表条目（包含Name、Nationality等属性）的大小相差不大，最终导致GSI总存储大小和原表接近。另外，DynamoDB的存储计算包含元数据、索引结构开销等，也会让两者的总大小更趋近。

高效实现“Name包含指定字符串”的方案 #

DynamoDB不支持原生模糊查询，可通过以下方式优化：

• 前缀匹配场景：修改GSI结构，用固定值（如NAME_PREFIX_INDEX）作为HASH键，name作为RANGE键，查询时用begins_with条件执行Query操作，直接利用索引定位数据，避免全表扫描。
• 关键词匹配场景：在原表新增keywords数组属性，预先把name拆分成关键词（比如“Picasso”）存入该数组，再创建以keywords为HASH键的GSI。查询时直接Query该GSI中HASH键等于目标关键词的条目，精准命中数据。
• 复杂模糊搜索：把DynamoDB数据同步到Elasticsearch/OpenSearch，利用全文搜索引擎实现高效的模糊匹配、分词搜索等复杂查询。

测试代码 #

var result = await _dynamoDb.ScanAsync(new ScanRequest(DynamoConstants.ArtistsTableName)
{
    IndexName = "NameIndex",
    FilterExpression = "contains(#Name, :name)",
    ExpressionAttributeNames = new Dictionary<string, string>() { { "#Name", "name" } },
    ExpressionAttributeValues = new Dictionary<string, AttributeValue>()
        { { ":name", new AttributeValue("Picasso") } }
});

索引创建代码 #

var nameIndex = new GlobalSecondaryIndex
{
    IndexName = "NameIndex",
    ProvisionedThroughput = new ProvisionedThroughput
    {
        ReadCapacityUnits = 5,
        WriteCapacityUnits = 5
    },
    Projection = new Projection { ProjectionType = "KEYS_ONLY" },
    KeySchema = new List<KeySchemaElement> {
        new() { AttributeName = "name", KeyType = "HASH"}
    }
};

内容的提问来源于stack exchange，提问作者rafał stempowski