Database Indexing easy
What happens to a B-Tree index over time as you delete and update many rows?
- A It becomes fragmented (leaf page bloat), potentially requiring a `REINDEX` or `VACUUM` to reclaim physical disk space and restore performance.
- B It implements a transparent, high-speed auto-compression routine that perfectly collapses all empty storage gaps without any external intervention.
- C It automatically converts itself into a Hash Index once a specific threshold of record deletions is reached to ensure that point-lookups remain O(1).
- D Nothing significant; B-Tree indexes are designed to be mathematically self-healing and maintain absolute efficiency regardless of the volume of updates.
Answer: A. It becomes fragmented (leaf page bloat), potentially requiring a `REINDEX` or `VACUUM` to reclaim physical disk space and restore performance.
In most databases, deleting a row doesn't immediately remove the entry from its indexes; it simply marks the leaf node as 'dead'. Over time, this creates 'fragmentation' where index pages are mostly empty but still take up disk space and stay in the database's memory cache. This leads to 'bloat', which slows down range scans and increases the overall memory footprint of the database, necessitating periodic maintenance like `VACUUM` in Postgres or `OPTIMIZE TABLE` in MySQL.
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'?
- Why is it generally ineffective to index a 'Low Cardinality' column like `Gender` ('Male'/'Female')?