Query Selectivity and Performance

// Selective: Id is always indexed, and this matches very few records
List<Account> account = [SELECT Id FROM Account WHERE Id = :specificId];

// Potentially non-selective: matches a large fraction of all records
List<Account> accounts = [SELECT Id FROM Account WHERE Industry != null];

1. // Selective: Id is always indexed, and this matches very few records — the label for the good example.
2. List<Account> account = [SELECT Id FROM Account WHERE Id = :specificId]; — a selective query's WHERE clause narrows the search down to a small percentage of the object's total records, using a field the database has indexed.
3. (blank line)
4. // Potentially non-selective: matches a large fraction of all records — the label for the risky example.
5. List<Account> accounts = [SELECT Id FROM Account WHERE Industry != null]; — a query whose filter matches most of an object's records isn't selective, no matter how the query is written.

Just like a book's index lets you jump straight to a topic instead of reading every page, an indexed database field lets Salesforce jump straight to matching records instead of scanning the entire table. Id and external Id fields (Module 19) are indexed automatically; other fields can be indexed by an admin when a query pattern needs it.

// On an object with 5 million records, this could time out
List<Account> accounts = [SELECT Id FROM Account WHERE CustomText__c LIKE '%import%'];

1. // On an object with 5 million records, this could time out — the scale that exposes the problem.
2. List<Account> accounts = [SELECT Id FROM Account WHERE CustomText__c LIKE '%import%']; — a non-selective query, especially a LIKE '%...%' pattern (which can't use most indexes at all), can simply time out rather than ever completing at that scale.

A small org's data rarely exposes this problem — this is why query performance, easy to ignore in a small dev org, becomes a real, load-bearing concern in production at scale.