12.3 Index Tuning
Add indexes only when they reduce read costs for actual predicates and join keys. Measure query latency, ingestion throughput, memory, and storage before and after creation.
Checks by table type
| Table type | Primary key or access path | Additional indexes |
|---|---|---|
| TAG | Name and BASETIME access | Supported value and metadata indexes |
| LOG | _ARRIVAL_TIME range | LSM, BITMAP, KEYWORD |
| LOOKUP | PRIMARY KEY | Supported secondary indexes |
| VOLATILE | Optional PRIMARY KEY | REDBLACK secondary indexes |
| TRANSACTION | PRIMARY KEY | Relational secondary indexes |
For supported index types and syntax, see each table type’s chapter and Index Syntax.
Procedure
- Record
EXPLAINand the result count for the slow SQL. - Check predicate selectivity and value distribution.
- Check for an existing index with the same leading column.
- Create one candidate index and verify that its build completes.
- Remeasure queries and ingestion under the same conditions.
- Remove indexes that provide no benefit or impose excessive write costs.
SHOW INDEXES;
SHOW INDEXGAP;Do not assume a fixed throughput reduction per index. Results depend on row size, key distribution, concurrency, and storage. Measure with data representative of production.
Considerations
- Compare against a scan before indexing a column with low selectivity.
- Check whether functions or casts around indexed columns prevent key-range access.
- Design composite indexes around frequent predicate combinations and leading columns.
- During index creation, monitor ingestion and query load and
SHOW INDEXGAP. - Before removing an unused index, verify that peak and batch workloads do not need it.
For details, see the index and performance pages in the TAG, LOG, LOOKUP, VOLATILE, and TRANSACTION chapters.
Last updated on