The query didn't change. What changed was how MySQL could find the rows. Here's what happened inside the database, with the real execution plans.

The experiment

I built a test table in MySQL 8 with random data, shaped like a real payments system:

• 2,020,000 payments across 100,000 customers

• one fund holding 95% of all rows (most systems have one very popular product)

• one big customer, 777, with 20,028 payments

CREATE TABLE payments (
    id          BIGINT AUTO_INCREMENT PRIMARY KEY,
    customer_id INT NOT NULL,
    fund_id     INT NOT NULL,
    paid_on     DATE NOT NULL,
    amount      DECIMAL(12,2) NOT NULL,
    INDEX idx_customer (customer_id),
    INDEX idx_fund (fund_id)
);

The full data-generation script is here: composite-index-demo.sql

The query is a classic balance lookup: one customer, one fund, everything up to today.

SELECT SUM(amount) FROM payments
WHERE customer_id = 777 AND fund_id = 1 AND paid_on <= '2026-10-12';

Both customer_id and fund_id already had indexes. So why did it take over a second?

Before: two indexes and an intersection

-> Aggregate: sum(payments.amount)  (actual time=1086..1086 rows=1)
    -> Filter: (fund_id = 1 and customer_id = 777 and paid_on <= '2026-10-12')
        -> Intersect rows sorted by row ID  (actual time=114..1075 rows=20028)
            -> Index range scan using idx_customer  (actual time=5.71..16 rows=20028)
            -> Index range scan using idx_fund      (actual time=9.36..897 rows=1.92e+6)

Read from the bottom up, MySQL:

1. used idx_customer to collect customer 777's row ids: 20,028 ids in 16 ms

2. used idx_fund to collect every fund-1 row id: 1.92 million ids in 897 ms

3. kept only the ids present in both lists (an "index intersection")

4. fetched those rows, checked the date, and summed the amounts

It read almost two million entries to answer a question about twenty thousand.

Why choose that plan? The optimizer's statistics estimated about 1 million fund-1 rows. There were actually 1.92 million. With the smaller estimate, intersecting looked cheaper than it really was.

A quick reminder: what an index is

An index is a sorted copy of one or more columns, stored as a B-tree. Because it's sorted, MySQL can walk down a few levels and land on the value it wants instead of reading every row.

In InnoDB, each entry in a secondary index is (indexed value, primary key), one entry per row. So idx_fund holds 1.92 million entries that start with 1. An index on a value shared by 95% of the table can't narrow anything down.

The composite index

CREATE INDEX idx_cust_fund_date_amount
ON payments (customer_id, fund_id, paid_on, amount);

This index is sorted by customer, then by fund within each customer, then by date within each fund, and it stores the amount alongside. All of customer 777's fund-1 payments now sit in one continuous block, already in date order.

After: 17 ms

-> Aggregate: sum(payments.amount)  (actual time=17..17 rows=1)
    -> Filter: (fund_id = 1 and customer_id = 777 and paid_on <= '2026-10-12')
        -> Covering index range scan using idx_cust_fund_date_amount
           over (customer_id = 777 AND fund_id = 1 AND paid_on <= '2026-10-12')
           (actual time=1.37..9.43 rows=20028)

One jump to (777, 1), then one walk forward through 20,028 entries, stopping at the date limit.

Covering means everything the query needs (customer, fund, date and amount) is inside the index, so MySQL never opened the table. I didn't force anything: the optimizer picked this index on its own.

The rules that make it work

1. Leftmost prefix. A composite index works like a phone book sorted by surname, then first name. You can find all the Mwangis, or "Mwangi, Kevin", but not all the Kevins, because they're spread under every surname.

My index helps queries on customer_id, or customer_id + fund_id, or all three. A query on fund_id alone can't use it:

EXPLAIN SELECT SUM(amount) FROM payments WHERE fund_id = 1;
-- key: idx_fund   (the composite index starts with customer_id)

2. Equality first, range last. customer_id = and fund_id = come before paid_on <=. Once the index reaches a range, the columns after it can't narrow the search any further.

3. Covering is a bonus. Adding amount let MySQL skip the table entirely. It's worth it for frequent queries, but every extra column makes the index bigger.

The trade-offs

• every INSERT, UPDATE and DELETE has to update every index

• each index takes disk space and memory

• a composite index only helps queries that match its column order

So I wouldn't add one just in case. Measure the slow query, read the plan with EXPLAIN ANALYZE, add the index, then measure again.

Takeaway

Single-column indexes each know one thing. A composite index knows the combination.

I'm Kevin Gakio, a backend engineer learning how databases work underneath.