Database Query Cost Calculator

Work out database query cost instantly with clear inputs, formula shown and shareable results.

About Database Query Cost Calculator

Databases read whole pages, so the cost of a query is pages touched rather than rows matched. Scanning 250,000 rows to return 40 means a selectivity of 0.016 percent and thousands of pages read for a handful of results — the classic signature of a missing index. Rows per page follows from row size and page size, which is also why narrow rows make scans cheaper.

Formula

Page-based cost

rows per page = floor(page size / row size); pages read = ceil(rows scanned / rows per page); selectivity = rows returned / rows scanned

Worked example

With the default values below, Database Query Cost Calculator returns Pages read of 10,000. Change any input above and every figure here is recalculated in your browser.

Inputs used

Rows scannedminimum 1: 250,000
Rows returnedminimum 1: 40
Average row sizeminimum 1 bytes: 320 bytes
Page sizeaccepts 1–64 KB: 8 KB

Results

Pages read: 10,000
Bytes read from storage or buffer pool: 78.13 MiB
Selectivity (returned / scanned): 0.0160%
Query efficiency: Extremely low selectivity - almost certainly a missing index

Step by step

1Values used
2Page-based cost
3Pages read= 10,000
4Bytes read from storage or buffer pool= 81,920,000
5Selectivity (returned / scanned)= 0.0160
6Query efficiency= Extremely low selectivity - almost certainly a missing index

Assumptions and limits

The result is derived only from the 4 inputs listed above. Anything not among them is not part of the calculation.
In particular, this calculator does not take inflation, tax, fees or charges or compounding frequency into account.
Figures are rounded for display to 4 decimal places, so totals built from several rounded parts can differ slightly from the unrounded arithmetic.

How these calculators are built and tested is described on the Methodology page. If a figure looks wrong, please report it.

Frequently Asked Questions

What selectivity justifies an index?

Below roughly 5 to 10 percent an index usually wins. Above that, the random I/O of index lookups plus row fetches can cost more than a sequential scan.

Does a covering index change this?

Substantially. If the index contains every column the query needs, the base table is never touched, which removes the row-fetch cost entirely.