What if your database could find combined info instantly, like flipping to the exact page in a book?
Why Composite indexes in MySQL? - Purpose & Use Cases
Imagine you have a huge phone book and you want to find people by both their last name and city. Without any special help, you have to flip through every page, checking each name and city one by one.
Doing this by hand is slow and tiring. You might miss some entries or take a long time to find what you want. In databases, searching without the right tools means the computer works harder and slower, especially when many people ask at once.
Composite indexes act like a smart guide that sorts the phone book first by last name, then by city. This way, the database quickly jumps to the right section, making searches much faster and more accurate.
SELECT * FROM contacts WHERE last_name = 'Smith' AND city = 'Boston'; -- no index, full scan
CREATE INDEX idx_name_city ON contacts(last_name, city); SELECT * FROM contacts WHERE last_name = 'Smith' AND city = 'Boston';
Composite indexes let databases find combined information quickly, making apps feel faster and more responsive.
Online stores use composite indexes to quickly find products by category and price range, so you see what you want without waiting.
Searching multiple columns without indexes is slow and inefficient.
Composite indexes speed up queries that filter by several columns together.
They help databases handle complex searches smoothly and quickly.
Practice
composite index in MySQL?Solution
Step 1: Understand what an index does
An index helps MySQL find data faster by organizing it for quick lookup.Step 2: Understand composite index purpose
A composite index uses multiple columns together to speed up queries that filter or sort by those columns combined.Final Answer:
To speed up queries that filter or sort by multiple columns together -> Option BQuick Check:
Composite index = speed up multi-column queries [OK]
- Thinking composite indexes store data
- Confusing indexes with backups
- Assuming encryption is related to indexes
first_name and last_name in a table users?Solution
Step 1: Recall correct CREATE INDEX syntax
The syntax is: CREATE INDEX index_name ON table_name (column1, column2);Step 2: Match syntax with options
CREATE INDEX idx_name ON users (first_name, last_name); matches the correct syntax with parentheses around columns and ON keyword before table name.Final Answer:
CREATE INDEX idx_name ON users (first_name, last_name); -> Option AQuick 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 people, which query will use the index efficiently?Solution
Step 1: Understand composite index column order
The index is on (city, age), so queries filtering city first then age use it best.Step 2: Analyze queries for index usage
SELECT * FROM people WHERE city LIKE '%Paris%' ORDER BY age DESC;: LIKE '%Paris%' prevents index use due to leading wildcard. SELECT * FROM people WHERE age = 30;: filters only age (second column), skips prefix. SELECT * FROM people WHERE age BETWEEN 20 AND 40;: range on age only, cannot use prefix. SELECT * FROM people WHERE city = 'Paris' AND age = 30;: city then age equality matches prefix perfectly.Final Answer:
SELECT * FROM people WHERE city = 'Paris' AND age = 30; -> Option AQuick Check:
Filter starts with first index column = SELECT * FROM people WHERE city = 'Paris' AND age = 30; [OK]
- Assuming any column filter uses composite index fully
- Ignoring column order in composite index
- Thinking ORDER BY always uses composite index
(department, salary) but your query SELECT * FROM employees WHERE salary > 50000; is slow. What is the likely problem?Solution
Step 1: Recall composite index usage rules
Composite indexes work best when queries filter starting from the first indexed column.Step 2: Analyze the query and index
The index is on (department, salary), but query filters only salary (second column), so index is not used efficiently, causing slowness.Final Answer:
The query does not filter on the first column of the composite index -> Option DQuick Check:
Filter must start with first index column [OK]
- Assuming any column filter uses composite index
- Blaming syntax without checking query
- Thinking numeric columns can't be indexed
orders with columns customer_id, order_date, and status. You often run this query:SELECT * FROM orders WHERE customer_id = 123 AND status = 'shipped' ORDER BY order_date DESC;Which composite index will optimize this query best?
Solution
Step 1: Identify query filter and order columns
The query filters by customer_id and status, then orders by order_date descending.Step 2: Choose index column order for best performance
Index should start with columns used in WHERE filters in order: customer_id, then status, then order_date for ORDER BY.Step 3: Match index options
CREATE INDEX idx_customer_status_date ON orders (customer_id, status, order_date); matches this order exactly, so it optimizes filtering and ordering best.Final Answer:
CREATE INDEX idx_customer_status_date ON orders (customer_id, status, order_date); -> Option CQuick Check:
Index columns match WHERE then ORDER BY order [OK]
- Putting ORDER BY column before filter columns
- Ignoring filter columns order
- Creating index missing important filter column
Ready to prove it?
Pass the test and this pattern moves unknown
