SQL Query Optimization: Execution Order, SARGable & Indexes

SQL Optimization · Query Performance · 2026 · 3,800 words · 4 interactive labs · April 2026

SQL Query
Optimization:
Execution Order,
SARGable & Indexes

Your SQL query looks perfectly reasonable. You've joined three tables, filtered by date, grouped by category, and returned 10 rows. It takes 8 seconds. Your coworker's query does the same thing and takes 40 milliseconds. The difference isn't luck — it's understanding what the database actually does with your SQL, and in what order. Here's everything they know that you don't yet.

Read the Deep Dive ↓ Open Query Lab ⚡ FROM→ WHERE→ GROUP BY→ HAVING→ SELECT→ ORDER BY→ LIMIT Table of Contents

1. Logical Execution Order
2. SARGable vs Non-SARGable Queries
3. Index Types & Join Optimization
4. Covering Indexes: Skip the Table
5. Handling Large Datasets & Pagination
6. Execution Plans: Read Before Optimizing

01The Logical Execution Order: Why Your SQL Lies to You

You write SQL top to bottom: SELECT columns, FROM table, WHERE conditions, GROUP BY, ORDER BY. It reads like a recipe. It looks sequential. And it is absolutely not executed that way. The database engine reads your SQL as a declaration of what you want, not a sequence of instructions. It then figures out the most efficient way to produce that result — and that order is fundamentally different from what you wrote.

The actual logical order of SQL execution: FROM and JOIN first — the database identifies the source data and how tables connect. WHERE next — filters rows before any grouping or aggregation. GROUP BY — organizes remaining rows into groups. HAVING — filters groups based on aggregate conditions (HAVING is to groups what WHERE is to rows). SELECT — only now does the database figure out which columns to project. ORDER BY — sorts the final result set. LIMIT — restricts the number of rows returned.

This order has profound performance implications that catch most developers off guard. The most common mistake: using a column alias defined in SELECT inside a WHERE clause. You've written SELECT price * 1.2 AS price_with_tax FROM orders WHERE price_with_tax > 100. This fails — because WHERE executes before SELECT, and price_with_tax doesn't exist yet when the WHERE clause runs. Understanding execution order is the prerequisite for understanding why this fails, and why the fix is a subquery or CTE rather than just moving things around.

Picture this: you're a librarian. A patron hands you a request: "From the history section, find all books published after 2010, group them by author, only show authors with more than 3 books, sorted by publication date, and give me just the first 20." You don't start by reading the books — you start by going to the history section (FROM), eliminating books published before 2010 (WHERE), grouping by author (GROUP BY), removing authors with ≤3 books (HAVING), and only then do you look at what specific columns you need to write on the slip (SELECT). The database is that librarian, working in the same order.

💡 ORDER BY and LIMIT Should Always Be a Pair

Here's the thing most tutorials miss: ORDER BY without LIMIT is almost always an expensive mistake in production queries. Sorting a million-row result set costs significant memory and CPU — the database must hold the entire result in memory, sort it, and then hand it to you. If you're paginating, use both LIMIT and ORDER BY together. If you're just checking "does this data exist," use EXISTS or LIMIT 1 instead of sorting. And if you need the maximum value, use MAX() instead of ORDER BY DESC LIMIT 1 — MAX() can often use an index directly without sorting the full dataset.

execution_order.sql — what runs when

-- Written order (how you read it):
SELECT customer_id, SUM(amount) AS total_spent
FROM orders
JOIN customers ON orders.customer_id = customers.id
WHERE orders.status = 'completed'
GROUP BY customer_id
HAVING SUM(amount) > 1000
ORDER BY total_spent DESC
LIMIT 10;

-- Execution order (what the DB actually does):
-- 1. FROM orders JOIN customers ON orders.customer_id = customers.id
-- 2. WHERE orders.status = 'completed' ← filters ROWS
-- 3. GROUP BY customer_id ← makes groups
-- 4. HAVING SUM(amount) > 1000 ← filters GROUPS
-- 5. SELECT customer_id, SUM(amount) ← projects columns
-- 6. ORDER BY total_spent DESC ← sorts result
-- 7. LIMIT 10 ← restricts rows

-- ❌ This FAILS (alias used before SELECT runs):
SELECT amount * 1.2 AS price_with_tax
FROM orders
WHERE price_with_tax > 100; -- alias doesn't exist yet!

-- ✓ Fix: use a subquery or CTE
WITH priced AS (
 SELECT *, amount * 1.2 AS price_with_tax FROM orders
)
SELECT * FROM priced WHERE price_with_tax > 100;

---

02SARGable Queries: The Difference Between Index Use and Full Table Scan

SARGable stands for Search Argument Able — a query predicate that the database engine can use an index to evaluate efficiently. The concept is one of the most important in SQL performance and one of the least-taught in general SQL education. Every developer who learns SQL learns about indexes. Very few learn about the conditions that silently make those indexes useless.

The rule is simple: if you wrap a column in a function inside a WHERE clause, the database cannot use an index on that column. WHERE YEAR(order_date) = 2023 looks innocent. The database sees it and thinks: "I need to evaluate YEAR() for every row to check if it equals 2023. I can't use the index on order_date because the index is sorted by order_date values, not by YEAR(order_date) values." The result: a full table scan across millions of rows. The SARGable equivalent — WHERE order_date >= '2023-01-01' AND order_date < '2024-01-01' — gives the database an exact range it can navigate directly with the index. The index on order_date is a sorted structure; jumping to '2023-01-01' is instant.

Common non-SARGable patterns and their fixes: using functions like UPPER(), LOWER(), TRIM(), CAST() on indexed columns in WHERE clauses; implicit type conversions (comparing a VARCHAR column to an integer forces the column to be cast); using LIKE with a leading wildcard (LIKE '%smith' can't use an index, but LIKE 'smith%' can); and arithmetic on the column side (WHERE salary / 12 > 5000 vs WHERE salary > 60000). The golden rule: in a WHERE clause, keep the column alone on the left side of the comparison operator. Anything that transforms the column makes it non-SARGable.

⚠️ The Hidden SARGability Killer: Implicit Type Conversion

One of the most insidious non-SARGable patterns is invisible in the code. If your user_id column is VARCHAR(36) and you query WHERE user_id = 12345 (passing an integer), the database may silently cast every row's user_id to an integer to compare — invalidating the index. Or the integer is cast to a string, which still works with the index. The behavior depends on the database. The fix: always match the data type of your parameter to the column's data type. Use WHERE user_id = '12345' for VARCHAR columns. In application code, be explicit about parameterized query types.

sargable.sql — non-SARGable vs SARGable patterns

-- ❌ NON-SARGABLE: function wrapped around column → full table scan
SELECT * FROM orders WHERE YEAR(order_date) = 2023;
SELECT * FROM users WHERE UPPER(email) = 'USER@EXAMPLE.COM';
SELECT * FROM orders WHERE amount / 100 > 50;
SELECT * FROM items WHERE name LIKE '%widget'; -- leading wildcard
SELECT * FROM users WHERE user_id = 12345; -- user_id is VARCHAR!

-- ✓ SARGABLE equivalents: column alone, comparison to literal/param
SELECT * FROM orders WHERE order_date >= '2023-01-01'
 AND order_date < '2024-01-01';
SELECT * FROM users WHERE email_lower = LOWER('USER@EXAMPLE.COM');
 -- store lowercase email as computed column!
SELECT * FROM orders WHERE amount > 5000; -- move math to literal side
SELECT * FROM items WHERE name LIKE 'widget%'; -- trailing wildcard: index works
SELECT * FROM users WHERE user_id = '12345'; -- match the column type

---

03Index Types & Join Optimization: Not All Indexes Are Equal

Most developers learn one thing about indexes: "add an index to columns you filter on." This is a good start and a vast oversimplification. Indexes are a data structure trade-off — they speed up reads at the cost of slowing down writes (every INSERT, UPDATE, DELETE must maintain all relevant indexes) and consuming disk space. The right index strategy requires understanding what types exist, when each performs best, and how joins interact with indexes.

B-Tree indexes are the default in virtually every database. They work by storing column values in a balanced tree structure, enabling O(log n) lookups, range queries, and prefix matching. B-Tree indexes are optimal for high-cardinality columns (columns with many distinct values — like email, user_id, order_date) and support both equality and range predicates. Bitmap indexes (primarily Oracle, though similar concepts appear in PostgreSQL with partial indexes) are optimized for low-cardinality columns (columns with few distinct values — like status, gender, country) by storing a bitmap for each distinct value indicating which rows match. Bitmap indexes are excellent for data warehouse queries with multiple low-cardinality filters but are poor choices for OLTP tables with frequent writes (every write must update multiple bitmaps).

Join optimization with indexes is where index strategy gets nuanced. The most important index for join performance: foreign keys. When you JOIN orders to customers on orders.customer_id = customers.id, the database needs to match each row in orders to its row in customers. Without an index on orders.customer_id, this is a nested loop join that scans the entire orders table for each customer row. With an index, the database can use a hash join or merge join strategy that's dramatically faster. The rule: every foreign key column should have an index unless you have a specific performance-tested reason not to.

🔬 Composite Index Column Order Is Everything

A composite index on (A, B) is useful for queries that filter on A alone or on A AND B. It is not useful for queries that filter on B alone — the index is sorted by A first, then B within each A value. If your most common query filters on B alone, you need a separate index on B (or the composite index column order reversed). The leading column of a composite index is the most critical selection. Start with the column that has the highest cardinality AND appears in the most queries, then add additional columns that appear frequently alongside it. Also: composite indexes can serve ORDER BY if the ORDER BY columns match the index column order.

---

04Covering Indexes: When the Database Never Touches the Table

A regular index helps the database find which rows match your query. But after finding those row IDs, the database still has to go back to the main table to retrieve the actual column values you requested in SELECT. This second trip is called a "key lookup" or "RID lookup" — and it's expensive when you're matching thousands of rows. A covering index eliminates this second trip entirely.

A covering index includes all the columns that a specific query needs — columns referenced in SELECT, WHERE, JOIN, and ORDER BY. When all needed columns are in the index, the database can satisfy the entire query from the index alone, never reading the main table. The performance difference can be dramatic: instead of reading index pages (small) and then table pages (much larger, often on disk), the database reads only the index. For a query that matches 10,000 rows across a 100-million-row table, the difference between a regular index and a covering index can be the difference between a 200ms query and a 5ms query.

The counterintuitive insight about covering indexes: they're sometimes better than adding more columns to your SELECT statement. If you have a query that almost never reads a certain column, and adding that column to your covering index would make the index 3× larger, it may be better to accept an occasional key lookup than to bloat an index that runs millions of times per day. Covering index design is a specific per-query optimization — build covering indexes for your most-frequent, most-expensive queries, not as a blanket strategy for all indexes.

✅ Use INCLUDE Columns for Covering Indexes in SQL Server / PostgreSQL

In SQL Server and PostgreSQL 11+, the INCLUDE clause lets you add extra columns to an index without including them in the sort key. This is crucial for covering indexes: you want to sort/filter on certain columns (they go in the key position) but need other columns just for SELECT (they go in INCLUDE). Example: CREATE INDEX idx_orders_covering ON orders(customer_id, order_date) INCLUDE (amount, status);. This index sorts by customer_id then order_date (enabling efficient range queries) and includes amount and status in the leaf nodes (enabling SELECT without a table lookup). INCLUDE columns don't affect sort order so they don't bloat intermediate B-Tree nodes — only the leaf pages.

covering_index.sql — design and verify

-- Query to optimize: run 10,000× per minute
SELECT order_id, amount, status
FROM orders
WHERE customer_id = 'cust_abc123'
 AND order_date >= '2023-01-01'
ORDER BY order_date DESC
LIMIT 20;

-- Columns needed: customer_id (WHERE), order_date (WHERE+ORDER BY),
-- order_id, amount, status (SELECT)

-- Regular index: finds rows but must go back to table for SELECT columns
CREATE INDEX idx_orders_customer ON orders(customer_id, order_date);

-- Covering index: satisfies ENTIRE query from index alone
-- (PostgreSQL 11+ / SQL Server syntax)
CREATE INDEX idx_orders_covering
ON orders(customer_id, order_date DESC)
INCLUDE (order_id, amount, status);

-- Verify: check EXPLAIN PLAN for "Index Only Scan" (PostgreSQL)
-- or "Index Scan" with no Key Lookup (SQL Server)
EXPLAIN ANALYZE
SELECT order_id, amount, status FROM orders
WHERE customer_id = 'cust_abc123'
AND order_date >= '2023-01-01'
ORDER BY order_date DESC LIMIT 20;
-- → "Index Only Scan using idx_orders_covering" ← perfect!

---

05Handling Large Datasets: Filter First, Sort Last, Page Wisely

The most expensive SQL operations — sorting, aggregation, joining — scale with the number of rows they operate on. Every optimization principle for large datasets follows from one insight: reduce the row count as early as possible in the execution pipeline. A WHERE clause that eliminates 95% of rows before GROUP BY dramatically reduces the work the grouping operation needs to do. A covering index that filters to 1,000 rows before ORDER BY dramatically reduces the sort cost compared to sorting 1,000,000 rows and then filtering.

Pagination is the most common large-dataset operation and the one most commonly implemented badly. The naive approach: SELECT * FROM orders ORDER BY created_at LIMIT 10 OFFSET 100000. This looks like it returns 10 rows. The database actually must sort 100,010 rows, skip the first 100,000, and return 10. The OFFSET doesn't skip work — it just discards it. At page 10,000 of a large table, this query scans and sorts millions of rows to return 10. The fix: keyset pagination (also called cursor pagination). Instead of OFFSET, use WHERE created_at > :last_seen_value ORDER BY created_at LIMIT 10, where last_seen_value is the last value from the previous page. The database jumps directly to that position in the index. Page 10,000 is exactly as fast as page 1.

💡 Keyset Pagination Is Strictly Better Than OFFSET for Performance

OFFSET pagination has one advantage: random access ("jump to page 500"). Keyset pagination requires starting from page 1 and paginating forward. For most real-world applications — social feeds, search results, data exports — this is not a limitation. Users rarely jump to page 500; they scroll forward. And for data exports, you process all records sequentially anyway. The performance difference makes keyset pagination non-negotiable for tables with millions of rows: OFFSET pagination at high page numbers causes timeouts and memory exhaustion that keyset pagination simply doesn't encounter. If random page access is genuinely required, paginate into a pre-generated page table or use Elasticsearch which handles this use case natively.

pagination.sql — offset (bad) vs keyset (good)

-- ❌ OFFSET pagination: slow at high page numbers
-- At page 10,000: scans & sorts 100,010 rows to return 10
SELECT id, title, created_at FROM articles
ORDER BY created_at DESC
LIMIT 10
OFFSET 100000; -- all 100,010 rows are sorted then 100,000 discarded

-- ✓ Keyset (cursor) pagination: always fast regardless of page
-- Client sends last_id from previous page
SELECT id, title, created_at FROM articles
WHERE created_at < :last_seen_timestamp -- or use id for tie-breaking
ORDER BY created_at DESC
LIMIT 10;
-- Index on (created_at DESC) → direct jump to position → returns 10 rows

-- Compound cursor for stable ordering with ties:
SELECT id, title, created_at FROM articles
WHERE (created_at, id) < (:last_ts, :last_id)
ORDER BY created_at DESC, id DESC
LIMIT 10;
-- Requires index on (created_at DESC, id DESC)

---

06Execution Plans: Read the Map Before Optimizing

Every database has a query planner that takes your SQL and devises an execution strategy. The execution plan is the map of that strategy — it shows you exactly what operations the database will perform, in what order, using which indexes, with estimated row counts and cost at each step. The single most important habit you can develop for SQL performance work: read the execution plan before changing anything.

In PostgreSQL, EXPLAIN ANALYZE runs the query and shows both the planned and actual execution. The critical things to look for: Sequential Scan on a large table means no index was used — investigate why. Index Scan means an index was used to find rows, but a key lookup is still needed for additional columns. Index Only Scan means a covering index is being used — the best possible outcome. For joins, look for nested loop joins on large tables (potentially expensive), hash joins (good for large tables without a useful index), and merge joins (good when both sides are sorted by the join key). The estimated vs actual row counts discrepancy is a key diagnostic: if the planner estimated 10 rows but got 10,000, your statistics are stale and need updating with ANALYZE.

The myth to bust: adding an index always makes the query planner use it. Database planners are sophisticated cost-based optimizers — they calculate the estimated cost of using the index vs not using it, and choose the cheaper option. If the table is small enough, a sequential scan is cheaper than an index scan (index overhead isn't free). If statistics are stale, the planner may choose a worse plan based on outdated row count estimates. If data distribution is skewed (90% of orders have status='completed'), the planner might correctly decide a sequential scan beats an index scan for WHERE status = 'completed'. Understanding why the planner made its decision is as important as knowing what plan it made.

⚡ Always Run ANALYZE After Bulk Data Changes

Database query planners make decisions based on table statistics — stored summaries of column value distributions, row counts, and histogram data. After a large INSERT, UPDATE, or DELETE, these statistics become stale. The planner's row count estimates diverge from reality, often causing dramatically suboptimal query plans. In PostgreSQL, run ANALYZE table_name; after large data changes. In SQL Server, statistics update automatically but can be manually triggered with UPDATE STATISTICS table_name;. In MySQL/MariaDB, run ANALYZE TABLE table_name;. In production systems processing large daily imports, scheduling an ANALYZE job after the import is standard practice.

execution_plans.sql — reading EXPLAIN output

-- PostgreSQL EXPLAIN ANALYZE output interpretation
EXPLAIN (ANALYZE, BUFFERS, FORMAT TEXT)
SELECT o.id, o.amount, c.name
FROM orders o
JOIN customers c ON o.customer_id = c.id
WHERE o.status = 'pending'
ORDER BY o.created_at DESC;

-- Typical output to analyze:
-- Sort (cost=24810.45..24811.20 rows=300 width=48)
-- (actual time=842.123..842.456 rows=298 loops=1)
-- -> Hash Join (cost=120.00..24795.30 rows=300 width=48)
-- Hash Cond: (o.customer_id = c.id)
-- -> Seq Scan on orders ← !! Full table scan — needs index!
-- Filter: (status = 'pending')
-- Rows Removed by Filter: 1299702
-- -> Hash (actual rows=50000)
-- -> Seq Scan on customers ← small table, scan is fine

-- What to do: add indexes
CREATE INDEX CONCURRENTLY idx_orders_status_date
 ON orders(status, created_at DESC)
 WHERE status IN ('pending', 'processing'); -- partial index!

CREATE INDEX CONCURRENTLY idx_orders_customer
 ON orders(customer_id);

-- Re-run EXPLAIN ANALYZE: should now show Index Scan instead of Seq Scan

---

synthesisHow It All Connects: The Complete SQL Optimization Mental Model

SQL optimization isn't a bag of tricks — it's a coherent mental model. The logical execution order tells you when each clause runs, which explains why aliases fail in WHERE and why you should filter with WHERE before HAVING. SARGability tells you whether your WHERE clause can use an index at all — and the rule is simple: keep the column bare, apply transformations to the other side. Index type and structure determine how efficiently the database navigates to matching rows. Covering indexes eliminate the second-trip key lookup. Execution plans reveal whether all this knowledge is actually being applied. And pagination strategy determines whether a query that's fast today stays fast as the dataset grows.

The workflow: write the query → read the execution plan → identify the most expensive operation → check if it's SARGable → check if the right index exists → check if a covering index would help → add the index → re-check the plan. Iterate. Never guess; always measure. The execution plan is your instrument panel, and no experienced pilot flies without looking at it.

---

FAQFrequently Asked Questions

What is the order of SQL execution? + SQL is executed in this order — which is different from the order you write it: (1) FROM and JOIN — identify and combine source tables. (2) WHERE — filter individual rows. (3) GROUP BY — group filtered rows. (4) HAVING — filter groups. (5) SELECT — determine which columns to return. (6) ORDER BY — sort the final result. (7) LIMIT — restrict row count. This order explains why column aliases defined in SELECT can't be used in WHERE (WHERE runs before SELECT), and why aggregate functions like SUM() can be used in HAVING but not in WHERE (aggregation happens after WHERE). Understanding this order is the foundation of writing correct, performant SQL. What does SARGable mean in SQL? + SARGable stands for "Search ARGument Able" — it describes a WHERE clause predicate that can be evaluated using an index. A SARGable predicate keeps the column alone on the left side of the comparison: WHERE order_date >= '2023-01-01'. A non-SARGable predicate wraps the column in a function: WHERE YEAR(order_date) = 2023. The difference: the index on order_date stores values in sorted order. The database can jump directly to '2023-01-01' in the index. But for YEAR(order_date), the database must compute YEAR() for every row to check if it equals 2023 — it can't navigate the index. Other non-SARGable patterns: LIKE '%value' (leading wildcard), implicit type conversions, arithmetic on the column side (column/12 > 5000), and most function calls applied to indexed columns. What is a covering index and when should I use one? + A covering index includes all columns that a specific query needs — columns referenced in SELECT, WHERE, JOIN, and ORDER BY. When a query can be satisfied entirely from the index without accessing the main table, it performs an "Index Only Scan" (PostgreSQL) or "Covering Index Scan" — eliminating expensive I/O to the main table. Use covering indexes for your highest-frequency, highest-cost queries where the performance difference matters at scale. Build a covering index by identifying all columns the query touches: key columns (used in WHERE, JOIN, ORDER BY) go in the sort position; additional SELECT columns go in INCLUDE (PostgreSQL 11+/SQL Server) or as additional key columns. Don't build covering indexes for every query — they consume disk space and slow down writes. Why is OFFSET pagination slow for large datasets? + OFFSET tells the database to skip a certain number of rows after sorting. But the database must still process (sort and rank) all the rows up to your OFFSET position to know which ones to skip. A query with OFFSET 100000 LIMIT 10 effectively processes 100,010 rows and discards 100,000 — the work scales linearly with the page number. At page 1000 of a large table, you're processing millions of rows to return 10. Keyset pagination (cursor pagination) avoids this: instead of OFFSET, you pass the last value seen from the previous page and use WHERE column > :last_value. The database uses an index to jump directly to that position — every page costs the same as page 1, regardless of how deep you go. How do I read a SQL execution plan? + An execution plan shows the operations the database performs, in what order, with what estimated costs and actual measurements. Key things to look for: Sequential Scan on a large table = no index used (investigate why — missing index, non-SARGable predicate, or the optimizer chose a scan because it's genuinely cheaper). Index Scan = index used to find rows, but must fetch additional columns from the table. Index Only Scan = covering index — ideal. For joins: Nested Loop Joins on large tables can be expensive; Hash Joins are typically good for large unsorted tables; Merge Joins are best when both sides are indexed by the join key. Also look at estimated vs actual row counts — large discrepancies mean stale statistics that need ANALYZE. What's the difference between WHERE and HAVING in SQL? + WHERE filters individual rows before grouping. HAVING filters groups after grouping and aggregation. Because of execution order (WHERE runs before GROUP BY, HAVING runs after), they operate on different things: WHERE can reference table columns directly, HAVING can reference aggregate functions like SUM(), COUNT(), AVG(). Common mistake: using HAVING when WHERE would work — WHERE is almost always faster because it reduces the row count before aggregation, giving GROUP BY less to process. Only use HAVING for conditions that involve aggregate functions: HAVING COUNT(*) > 5, HAVING SUM(amount) > 1000. For non-aggregate conditions that could go in either place, always prefer WHERE. When should I add an index vs avoid one? + Add an index when: a column appears frequently in WHERE, JOIN, or ORDER BY clauses; the column has high cardinality (many distinct values — IDs, emails, timestamps); the query runs frequently enough that optimization pays off; the table is large (indexes matter less on tiny tables). Avoid indexes when: the table is small (sequential scans are fast on small tables and index overhead isn't justified); the column has very low cardinality (status columns with 3-4 values — consider partial indexes instead); the table has extremely high write rates (every write must update all indexes — too many indexes can slow inserts/updates more than they help reads); the column is rarely queried. Rule of thumb: measure first with EXPLAIN. If the most expensive queries show Sequential Scans on large tables, add indexes. If writes are slow, audit and remove unused indexes. How does GROUP BY affect SQL query performance? + GROUP BY is an expensive operation — the database must collect all rows matching each group value, which often requires sorting or hash aggregation. Key optimizations: (1) Filter first with WHERE to reduce the number of rows before GROUP BY processes them. More rows filtered = cheaper grouping. (2) Use indexes on GROUP BY columns when possible — if an index on the grouping column exists, the database can retrieve groups directly from the index without sorting. (3) On large result sets, consider materialized views or pre-aggregated summary tables that store GROUP BY results — querying a summary table is dramatically faster than aggregating millions of rows at query time. (4) Watch for GROUP BY on high-cardinality columns (millions of distinct values) — this creates millions of groups and can consume significant memory.

⚡ SQL Query Lab

Four experiments: execution order animator, SARGability checker, index cost simulator, and pagination comparison.

SQL logical execution order — click each step to see what it processes

Execution Order Visualizer

Click each step to see what data it processes and how many rows it produces.

— Rows in — Rows out Query SARGability Checker Enter your WHERE clause Common patterns to test Analysis Result SARGable fix — Index usable? — Scan type

Query cost: no index vs index vs covering index

Index Cost Simulator Table rows (millions) 5M Selectivity (% rows matched) 0.1% SELECT columns in index? No — No index (ms) — With index (ms) — Covering index (ms) — Speedup factor

Query cost vs page number — OFFSET (red) vs Keyset (green)

Pagination Cost Comparison Table size (rows) 1M Page size (rows per page) 20 Current page number 500 — OFFSET rows scanned — Keyset rows scanned — OFFSET time (est) — Keyset time (est)