Mark has a dashboard that shows orders for a chosen day, and on the production database it’s become slow. “Same query as always. Why is it suddenly slow?” On Cartwheel’s two thousand orders, every query in this course returns instantly. Production has years of orders, and there the difference between a query that reads every row and one that jumps to the right rows is seconds versus minutes. You can’t feel that difference on a small database, but you can see it in the query plan.
\nAn index is a separate structure that keeps the values of one or more columns in sorted order, each with a pointer to its row. Finding ‘2025-11-28’ in a sorted list is like finding a word in a dictionary: you jump to roughly the right page instead of reading from the start. Without an index, the database has to read the whole table and test every row, which is a scan.
\nCartwheel’s database has a few indexes already. You can list them from the schema table:
\nSELECT name, tbl_name, sql\nFROM sqlite_schema\nWHERE type = 'index';orders is indexed on customer_id and order_date, order_items on order_id and product_id. The sqlite_autoindex_customers_1 entry exists because email is declared UNIQUE; SQLite enforces uniqueness with an index.
Prefix any SELECT with EXPLAIN QUERY PLAN and SQLite describes how it will run it instead of running it. The interesting part is the detail column:
EXPLAIN QUERY PLAN\nSELECT order_id, status\nFROM orders\nWHERE order_date >= '2025-11-28'\n AND order_date < '2025-11-29';SEARCH orders USING INDEX idx_orders_date (order_date>? AND order_date<?). SEARCH means the index narrowed the work to a range. Now Mark’s dashboard query, which someone “simplified” last month:
EXPLAIN QUERY PLAN\nSELECT order_id, status\nFROM orders\nWHERE date(order_date) = '2025-11-28';SCAN orders. Same result, but now every row is read and date() is computed for each one. The index stores raw order_date values; it knows nothing about date(order_date), so it can’t help. That’s the “suddenly slow”.
Two more plan phrases are worth recognising. USING COVERING INDEX means the index alone held every column the query needed, so the table wasn’t touched at all, the fastest kind of lookup. And USE TEMP B-TREE FOR GROUP BY or FOR ORDER BY means SQLite had to sort rows itself, which is fine on small results and worth a look on large ones.
Plans for joins show one line per table, in the order SQLite visits them:
\nEXPLAIN QUERY PLAN\nSELECT o.order_id, SUM(oi.quantity) AS units\nFROM orders AS o\nJOIN order_items AS oi ON oi.order_id = o.order_id\nWHERE o.customer_id = 42\nGROUP BY o.order_id;Both lines say SEARCH: find customer 42’s orders through idx_orders_customer, then each order’s items through idx_items_order. An index on every foreign key you join on is the single most valuable indexing habit.
A query plan is the optimizer’s choice, not a guarantee of speed, and it depends on the data. On a tiny table the optimizer may decide a scan is cheaper than an index, and it’ll be right. Both engines can keep statistics about each table, gathered by the ANALYZE command (PostgreSQL’s autovacuum runs it for you; in SQLite someone has to run it), and use them to estimate how many rows each step returns. When those statistics are stale, plans go wrong in surprising ways, which is one more question to ask the database owner about a query that slowed down “for no reason”.
Some filters can’t use an ordinary index however you write them. name LIKE '%mat%' has to look inside every value, because a sorted list can’t help you find text in the middle of words. If a search like that is frequent, the answer is a different tool, such as full-text search, rather than another index.
Analysts often don’t own the schema, but you’ll be the one who notices the slow query. Support filters tickets by opened_at constantly, and that column has no index, so the plan for those queries is a SCAN. The request to the database owner would be:
CREATE INDEX idx_tickets_opened_at ON support_tickets (opened_at);Indexes aren’t free. Each one takes storage and must be updated on every insert, update and delete, so a table with ten indexes writes noticeably slower. Ask for indexes on columns that frequent queries filter, join or sort on, and that narrow the result a lot. An index on status, with five values, rarely helps; an index on a date or an id usually does. For a multi-column index, put the column you test with = first and the range column second: (customer_id, order_date) serves “customer 42’s orders in 2025” with one search.
Fast queries are only useful if people can read them. Next: the style habits and dialect differences that make your SQL reviewable and portable.
\n","toc":[{"id":"sec-1","text":"What an index is","level":2},{"id":"sec-2","text":"Reading a query plan","level":2},{"id":"sec-3","text":"Plans are predictions","level":2},{"id":"sec-4","text":"When to ask for a new index","level":2}],"takeaways":["An index is a sorted copy of one or more columns with pointers back to the rows, so the database can jump to matching values instead of reading every row.","In EXPLAIN QUERY PLAN, SEARCH … USING INDEX means the index narrowed the work; SCAN means every row (or every index entry) was read.","Wrapping an indexed column in a function or arithmetic, like date(order_date), usually stops the index from being used; compare the bare column with a range instead.","Indexes speed up reads but cost storage and slow down every insert and update, so add them for frequent, selective filters and join keys."],"further":[{"title":"SQLite EXPLAIN QUERY PLAN","url":"https://www.sqlite.org/eqp.html"},{"title":"SQLite query optimizer overview","url":"https://www.sqlite.org/optoverview.html"},{"title":"PostgreSQL using EXPLAIN","url":"https://www.postgresql.org/docs/current/using-explain.html"}],"quiz":[{"q":"orders has an index on order_date. Which filter for orders on 28 November 2025 can use it as a SEARCH?
WHERE date(order_date) = '2025-11-28'","why":"The index stores raw order_date values, not date(order_date), so the database has to compute the function for every row."},{"text":"WHERE strftime('%Y-%m-%d', order_date) = '2025-11-28'","why":"Same problem in a different function; any expression wrapped around the column hides it from the index."},{"text":"WHERE order_date >= '2025-11-28' AND order_date < '2025-11-29'","why":"Correct. The bare column is compared with constants, so the database can seek to the start of the range in the sorted index and stop at the end."}],"answer":2},{"q":"A plan shows SCAN orders USING COVERING INDEX idx_orders_date. What does that mean?
An analytics database gets a million new web sessions a day and is queried a few times a day by source. Someone proposes indexes on all nine columns of web_sessions. What’s the best response?
customer_id only, because ids are always the best index.","why":"The best index matches how the table is queried. Nothing in the scenario filters by customer."},{"text":"Index the columns that real, frequent queries filter or join on, check the plans, and skip the rest.","why":"Correct. Every index has a write and storage cost, so add the ones that serve actual queries and confirm with EXPLAIN QUERY PLAN that they’re used."}],"answer":3},{"q":"In PostgreSQL, what does EXPLAIN ANALYZE do that EXPLAIN doesn’t?
Mark’s dashboard shows orders per day for the Black Friday weekend, Friday 28 November to Monday 1 December 2025 inclusive (all statuses).
\nReturn day (‘YYYY-MM-DD’) and orders, sorted by day. Order matters. The starter’s filter is index-friendly but drops a whole day.
Fix it so the result is complete and the filter still uses idx_orders_date: run your query with EXPLAIN QUERY PLAN in front and check that the plan says SEARCH, not SCAN.
date(order_date) BETWEEN ..., would fix the count but turn the plan into a SCAN.","Use a half-open range on the bare column: order_date >= '2025-11-28' AND order_date < '2025-12-02'."],"explanation":"BETWEEN '2025-11-28' AND '2025-12-01' stops at midnight at the start of 1 December, so Cyber Monday disappears. date(order_date) BETWEEN ... returns the right rows but makes SQLite compute date() for every order, a full scan. The half-open range keeps the bare indexed column on one side of each comparison, so the plan reads SEARCH orders USING COVERING INDEX idx_orders_date, and it includes all of Monday: 15, 12, 11 and 4 orders.