What if your database could find complex data instantly, like flipping straight to the right page in a book?
Why Composite index and column order in SQL? - Purpose & Use Cases
Imagine you have a huge phone book sorted by last name and first name separately. When you try to find a person by both names together, you have to flip through pages multiple times, making the search slow and frustrating.
Searching without a combined order means scanning many entries repeatedly. This wastes time and can cause mistakes, especially when data grows large. Manually sorting or searching each column one by one is slow and error-prone.
A composite index sorts data by multiple columns in a specific order, like sorting the phone book first by last name, then by first name. This makes searching for combined values fast and efficient, reducing the time and effort drastically.
SELECT * FROM contacts WHERE last_name = 'Smith' AND first_name = 'John'; -- no composite index, full scan
CREATE INDEX idx_name ON contacts(last_name, first_name); -- fast lookup using composite index
It enables lightning-fast searches on multiple columns together, making your database queries much quicker and more reliable.
When an online store wants to quickly find orders by customer ID and order date, a composite index on these two columns helps show results instantly, improving user experience.
Manual searches on multiple columns are slow and inefficient.
Composite indexes sort data by multiple columns in order, speeding up queries.
Proper column order in the index is key for best performance.
Practice
composite index in a database?Solution
Step 1: Understand what a composite index does
A composite index is created on multiple columns to help the database find rows faster when queries filter on those columns together.Step 2: Compare options to the definition
Only It speeds up queries filtering on multiple columns together. correctly describes the benefit of speeding up queries using multiple columns. Other options describe unrelated features.Final Answer:
It speeds up queries filtering on multiple columns together. -> Option DQuick Check:
Composite index = speeds up multi-column queries [OK]
- Thinking it reduces database size
- Confusing indexing with backup or encryption
- Assuming it speeds up single-column queries only
last_name and first_name in a table employees?Solution
Step 1: Recall correct CREATE INDEX syntax
The correct syntax is: CREATE INDEX index_name ON table_name (column1, column2);Step 2: Match options to syntax
CREATE INDEX idx_name ON employees (last_name, first_name); matches the correct syntax exactly. Options A, C, and D have syntax errors or misplaced keywords.Final Answer:
CREATE INDEX idx_name ON employees (last_name, first_name); -> Option BQuick Check:
CREATE INDEX ... ON table (columns) [OK]
- Omitting parentheses around columns
- Placing columns before ON keyword
- Using WHERE instead of column list
(city, age) in a table users, which query will use the index efficiently?Solution
Step 1: Understand index column order usage
A composite index on (city, age) can be used efficiently if the query filters on city first, then age.Step 2: Analyze each query
SELECT * FROM users WHERE city = 'Boston' AND age > 30; filters on city and age, matching index order. SELECT * FROM users WHERE age > 30; filters only on age (second column), so index is less useful. SELECT * FROM users WHERE age = 25 AND city = 'Boston'; filters age first, then city, which is less efficient. SELECT * FROM users WHERE city = 'Boston' ORDER BY age DESC; filters city but only orders by age, which may use index partially.Final Answer:
SELECT * FROM users WHERE city = 'Boston' AND age > 30; -> Option CQuick Check:
Index (city, age) best for city then age filters [OK]
- Assuming index works well if filtering only second column
- Ignoring column order in composite index
- Thinking ORDER BY always uses index fully
(department, salary) but your query filtering only on salary is slow. What is the likely cause?Solution
Step 1: Recall how composite index column order affects usage
Composite indexes work best when filtering starts with the first column. Filtering only on the second column (salary) won't use the index efficiently.Step 2: Evaluate options
The index column order starts with department, so filtering only salary can't use it well. correctly explains the cause. Options A, B, and D are unlikely or incorrect because the index exists and salary can be indexed normally.Final Answer:
The index column order starts with department, so filtering only salary can't use it well. -> Option AQuick Check:
Filter must start with first index column [OK]
- Assuming any column in index can be filtered efficiently alone
- Blaming index corruption without checking usage
- Ignoring column order importance
orders with columns customer_id, order_date, and status. You often run queries filtering by customer_id and sorting by order_date. Which composite index will optimize these queries best?Solution
Step 1: Identify query filter and sort columns
Queries filter by customer_id and sort by order_date, so index should start with customer_id and include order_date next.Step 2: Match index column order to query pattern
CREATE INDEX idx_customer_date ON orders (customer_id, order_date); matches this order (customer_id, order_date), allowing efficient filtering and sorting. CREATE INDEX idx_date_customer ON orders (order_date, customer_id); reverses order, less efficient for filtering. Options A, B, and C do not match query needs.Final Answer:
CREATE INDEX idx_customer_date ON orders (customer_id, order_date); -> Option AQuick Check:
Index columns match filter then sort order [OK]
- Reversing column order in composite index
- Indexing unrelated columns
- Using single-column index when composite needed
Ready to prove it?
Pass the test and this pattern moves unknown
