How an index works (B-tree mental model) in SQL - Performance & Efficiency
We want to understand how fast searching is when using an index in a database.
Specifically, how the work grows as the data gets bigger.
Analyze the time complexity of this query using a B-tree index.
SELECT * FROM employees
WHERE employee_id = 12345;
-- Assume employee_id is indexed with a B-tree
This query looks up one employee by their ID using a B-tree index.
Look at what repeats when searching the B-tree.
- Primary operation: Comparing the search key to node keys in the B-tree.
- How many times: Once per tree level, moving down from root to leaf.
As the number of employees grows, the tree gets taller slowly.
| Input Size (n) | Approx. Operations |
|---|---|
| 10 | About 2 comparisons |
| 100 | About 3 comparisons |
| 1000 | About 4 comparisons |
Pattern observation: The number of steps grows very slowly, adding just one step for about every 10 times more data.
Time Complexity: O(log n)
This means the search time grows slowly as data grows, making lookups efficient even for large data.
[X] Wrong: "Searching an index is as slow as scanning all rows one by one."
[OK] Correct: The B-tree index lets the database skip most rows by jumping through tree levels, so it does not check every row.
Knowing how indexes speed up searches helps you explain database efficiency clearly and confidently.
"What if the index was a simple list instead of a B-tree? How would the time complexity change?"
Practice
Solution
Step 1: Understand what a B-tree index does
A B-tree index organizes data in a balanced tree structure to allow quick searching without scanning the entire table.Step 2: Compare options with B-tree purpose
Only To speed up data retrieval by organizing data in a balanced tree structure describes speeding up data retrieval using a balanced tree, which matches the B-tree index function.Final Answer:
To speed up data retrieval by organizing data in a balanced tree structure -> Option AQuick Check:
B-tree index = fast data lookup [OK]
- Thinking indexes store data randomly
- Confusing index with data compression
- Believing indexes backup data
last_name of the table employees?Solution
Step 1: Identify default index type in SQL
By default,CREATE INDEXcreates a B-tree index unless specified otherwise.Step 2: Check syntax correctness
CREATE INDEX idx_last_name ON employees (last_name); uses correct syntax without specifying a different index type, so it creates a B-tree index onlast_name.Final Answer:
CREATE INDEX idx_last_name ON employees (last_name); -> Option CQuick Check:
Default index type = B-tree [OK]
- Using HASH or FULLTEXT without need
- Adding unsupported index types like BITMAP in standard SQL
- Incorrect syntax for index creation
products with a B-tree index on product_id, what will the query optimizer most likely do when running:SELECT * FROM products WHERE product_id = 123;?Solution
Step 1: Understand query condition and index
The query searches for a specificproduct_idvalue, which matches the indexed column.Step 2: Predict optimizer behavior with B-tree index
The optimizer uses the B-tree index to quickly find the matching row without scanning the whole table.Final Answer:
Use the B-tree index to quickly locate the row with product_id 123 -> Option AQuick Check:
Indexed search = fast lookup [OK]
- Assuming full table scan always happens
- Confusing B-tree with hash index usage
- Thinking partial scan happens without index
email column of the users table, but queries filtering by email are still slow. What is a likely cause?Solution
Step 1: Analyze query and index interaction
If the query applies a function (like LOWER(email)) on the indexed column, the B-tree index cannot be used directly.Step 2: Evaluate other options
The index was created on the wrong column is unlikely if index was created correctly; C is false because B-tree indexes work on text; D is possible but less likely than B.Final Answer:
The query uses a function onemailpreventing index use -> Option BQuick Check:
Functions on indexed columns block B-tree use [OK]
- Assuming B-tree indexes don't work on text
- Ignoring query transformations on columns
- Blaming index creation without checking query
orders with columns order_id, customer_id, and order_date. You often query orders by customer_id and sort by order_date. How should you create an index to optimize these queries?Solution
Step 1: Understand query pattern
Queries filter bycustomer_idand sort byorder_date, so both columns matter together.Step 2: Choose index type for filtering and sorting
A composite B-tree index on (customer_id,order_date) supports filtering by customer and sorting by date efficiently.Final Answer:
Create a composite B-tree index on (customer_id,order_date) -> Option DQuick Check:
Composite index matches filter + sort columns [OK]
- Creating index only on sort column
- Using separate indexes instead of composite
- Choosing hash index which doesn't support sorting
Ready to prove it?
Pass the test and this pattern moves unknown
