Local Secondary Index Considerations
When querying a local secondary index, the number of read capacity units consumed depends on how the data is accessed. For example, when you create a local secondary index and project non-key attributes into the index from the parent table, Amazon DynamoDB can retrieve these projected attributes efficiently.
In addition, when you query a local secondary index, the query can also retrieve attributes that are not projected into the index. Avoid these types of index queries that read attributes that are not projected into the local secondary index. Fetching attributes from the parent table that are not specified in the local secondary index causes additional latency in query responses and incurs a higher provisioned throughput cost.
Tip
Project frequently accessed non-key attributes into a local secondary index to avoid fetches and improve query performance.
Maintain multiple local secondary indexes in tables that are updated infrequently but are queried using many different criteria to improve query performance. This guidance does not apply to tables that experience heavy write activity.
If very high write activity to the table is expected, one option to consider is to minimize interference from reads by not reading from the table at all. Instead, create a global secondary index with a structure that is identical to that of the table, and then direct all queries to the index rather than to the table.
