-- Table structure with ORDER BY, PRIMARY KEY, indexes
SHOW
CREATE
TABLE
{
database
}
.
{
table
}
-- Skipping indexes
SELECT
name
,
type
,
expr
,
granularity
FROM
system
.
data_skipping_indices
WHERE
database
=
'{database}'
AND
table
=
'{table}'
Step 2: Extract Query Patterns
Run the WHERE column extraction and normalized pattern queries to understand:
Which columns appear most frequently in WHERE clauses
What condition combinations are common
Step 3: Check Column Cardinalities
Compare cardinalities of columns in:
Current ORDER BY key
Frequently filtered columns from Step 2
Step 4: Evaluate Index Alignment
Query Pattern
Index Support
Action
Filters on ORDER BY prefix
✅ Good
None
Filters on non-ORDER BY cols
⚠️ Skip index?
Add bloom_filter or projection
Time range + entity
⚠️ Check order
Time in ORDER BY or partition?
High-cardinality first in ORDER BY
❌ Bad
Reorder (low→high cardinality)
ORDER BY Design Guidelines
Column Order Principles
Lowest cardinality first
- maximizes granule skipping
Most frequently filtered
- columns in WHERE should be in ORDER BY
Time column considerations:
If most queries filter on time ranges → include in ORDER BY (possibly with lower resolution like
toDate(ts)
)
If partition key handles time filtering → may not need in ORDER BY
Common Anti-Patterns
Anti-Pattern
Problem
Fix
High-cardinality UUID first
No granule skipping
Move after low-cardinality columns
DateTime64 microseconds first
Too granular
Use
toDate()
or
toStartOfHour()
Column in WHERE not in ORDER BY
Full scan
Add to ORDER BY or create projection
Bloom filter on ORDER BY column
Redundant
Remove skip index
Time not in ORDER BY or partition
Range queries scan all
Add
toDate(ts)
to ORDER BY prefix
Cardinality Ordering Example
Given cardinalities:
entity_type
6
entity
18,588
cast_hash
335,620
Recommended ORDER BY:
(entity_type, entity, cast_hash, ...)
Skipping Index Guidelines
When Skip Indexes Help
Column NOT in ORDER BY
Column values correlate with physical data order
Low false-positive rate for the index type
When Skip Indexes Don't Help
Column already in ORDER BY prefix (use PRIMARY KEY instead)
Column values randomly distributed (no correlation with ORDER BY)
Very high cardinality with set/bloom_filter