Index Selectivity
The fraction of rows a predicate eliminates — the property that determines whether an index is worth using at all.
An index on a column with two distinct values across ten million rows is close to useless: matching half the table means the engine must fetch five million rows individually, which is slower than scanning the table sequentially. The planner knows this, ignores the index, and the developer concludes the index is "not working".
High selectivity — an email address, an order ID, a timestamp — means the predicate eliminates almost everything, so the index does real work.
Two refinements worth knowing. Composite indexes derive selectivity from the combination, so
(status, created_at) can be highly selective even though status alone is not — which is why column
order matters and why the low-cardinality column belongs first when it is an equality predicate.
And skewed distributions break the average: a status column that is 99% completed is highly
selective for every other value, which is what histogram statistics exist to capture.
The practical instruction: never add an index without checking the plan afterwards. An unused index has all of the write cost and none of the benefit, and nobody ever removes it.