Database Indexing easy
When might the database optimizer intentionally choose a Full Table Scan over an Index?
- A When the table is exceptionally small (e.g., under 100 rows) or the query is expected to return a large majority of the table's total records.
- B Whenever the query targets a Primary Key column, as the database prefers the physical reliability of a full-disk scan over a tree-based lookup.
- C Whenever the query includes a strict `LIMIT 1` clause, as the database can often find a single matching record faster by scanning from the beginning of the file.
- D Whenever the query is initiated by a user with administrative privileges to ensure that all internal database statistics and caches are fully refreshed.
Answer: A. When the table is exceptionally small (e.g., under 100 rows) or the query is expected to return a large majority of the table's total records.
An index is not always the fastest path. If a table consists of only a few dozen rows, the database can read the entire table into memory in a single I/O operation faster than it can navigate a multi-level B-Tree. Similarly, if your query fetches 30% or more of the table, the 'cost' of jumping back and forth between the index and the data pages (Random I/O) outweighs the speed of simply reading the entire table sequentially (Sequential I/O).
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')?