Database Indexing easy
Why is it generally ineffective to index a 'Low Cardinality' column like `Gender` ('Male'/'Female')?
- A Standard B-Tree indexes are strictly limited to numeric identifiers and cannot store variable-length string data like `Gender` categories.
- B If a query returns a large percentage of the table (>20%), a Sequential Scan is significantly faster than performing thousands of random index seeks.
- C Low cardinality indexes consume a disproportionate amount of physical disk storage due to the way they handle internal page-filling policies.
- D Filtering by low cardinality columns causes the database engine to acquire aggressive, table-level locks that frequently lead to application deadlocks.
Answer: B. If a query returns a large percentage of the table (>20%), a Sequential Scan is significantly faster than performing thousands of random index seeks.
Indexes are designed to find 'needles in haystacks' (high selectivity). If you are querying for all 'Females' in a database where they make up 50% of the rows, the database optimizer will likely ignore the index. It is more efficient to perform a 'Sequential Scan' (reading the table line-by-line) than to perform millions of 'Index Seeks' (which involve high-latency random disk I/O to jump between the index and the table data).
One system design question a day, with spaced repetition so the ones you miss come back.
Get the appRelated questions
- Z-Order Curves (Geohashing) map 2D data to 1D strings for indexing. What is their primary weakness?
- In-Memory databases (Hyper, HANA) often favor Adaptive Radix Trees (ART). Why?
- Log-Structured Merge (LSM) Trees (RocksDB, Cassandra) optimize for Write Throughput. How does their disk IO pattern differ from B-Trees?
- In LSM compaction strategies, 'Universal' (Tiered) compaction prioritizes what over 'Leveled' compaction?
- In LSM trees, what is 'Space Amplification'?
- You have a composite index on `(Lastname, Firstname)`. Which query can efficiently use this index?