A predicate is SARGable — from "Search ARGument ABLE" — when SQL Server can use an index to satisfy it with a seek instead of scanning every row.
The fastest way to make a query non-SARGable is to wrap a column in a function or compare mismatched data types in the WHERE clause. That forces SQL Server to evaluate every row, turning a quick seek into an expensive scan.
SARGability is one of the highest-impact, lowest-effort tuning concepts: a one-line rewrite of a predicate can turn a full scan into a seek and cut a query's work by orders of magnitude. This guide shows what breaks it and how to fix it.
Seek vs. scan: why it matters
An index seek reads only the matching rows; an index scan reads everything and then filters. The cost difference grows with table size — on a large table, a seek touches a handful of pages while a scan touches them all. A SARGable predicate is simply one written so SQL Server is able to seek.
SARGable vs. non-SARGable
| Usually SARGable | Usually non-SARGable |
|---|---|
=, >, >=, <, <= | Function on a column: YEAR(col), UPPER(col) |
BETWEEN, IN | Implicit type conversion on a column |
LIKE 'term%' (prefix) | LIKE '%term' (leading wildcard) |
| A bare column on one side | NOT, <>, NOT IN |
Offender #1: functions on columns
An index stores raw column values, not the output of a function applied to them. So the moment you wrap the column, SQL Server can no longer match the index and must compute the function for every row. The fix is to keep the column bare and move the logic to the other side — usually as a range:
Non-SARGable → SARGable-- Non-SARGable: function on the column forces a scan
WHERE YEAR(OrderDate) = 2026
-- SARGable: a date range lets SQL Server seek the index
WHERE OrderDate >= '2026-01-01'
AND OrderDate < '2027-01-01'
Offender #2: implicit conversions
When a predicate compares two different data types, SQL Server implicitly converts one side to match the other. If it has to convert the column side (for example, comparing an NVARCHAR column to a VARCHAR literal, depending on precedence), it effectively applies a function to every row — and the plan shows a CONVERT_IMPLICIT warning. Match the literal's type to the column's type to keep the predicate SARGable.
You will usually first notice a SARGability problem as a scan or a conversion warning in the execution plan — and you will measure the fix as a drop in logical reads.
A note on NULLs and edge cases
Not every "non-SARGable" pattern can be rewritten, and some rewrites change meaning — particularly around NULL handling and OR conditions. As always, a rewrite is only valid if it returns identical results; verify equivalence before trusting it. That correctness-first discipline is the heart of the optimization loop.
How automated analysis catches it
Non-SARGable predicates are a textbook pattern for an AI analysis step: the plan shows the scan and the conversion warning, and the rewrite to a range or a type-matched comparison is mechanical. SprocOptimizer flags non-SARGable predicates as part of its analysis and proposes SARGable rewrites — which are then verified for logical equivalence and validated against your real parameters before promotion, so a "faster" predicate can never quietly change your results.
Frequently asked questions
SARGable is short for Search ARGument ABLE. A predicate is SARGable when the SQL Server query engine can use an index to satisfy it with a seek rather than scanning every row. SARGable predicates let SQL Server jump straight to the matching rows, which is dramatically faster than reading the whole table or index.
The most common cause is applying a function or calculation to a column in the WHERE clause, such as YEAR(OrderDate) = 2026 or UPPER(LastName) = 'SMITH'. A leading-wildcard LIKE ('%term') and implicit data-type conversions on a column also defeat SARGability. Operators like NOT, <>, and NOT IN are generally non-SARGable as well. In each case SQL Server must evaluate every row instead of seeking.
Keep the column bare on one side of the comparison and move any logic to the other side. Replace WHERE YEAR(OrderDate) = 2026 with a range: WHERE OrderDate >= '2026-01-01' AND OrderDate < '2027-01-01'. Match data types so no implicit conversion is needed, and avoid leading wildcards in LIKE. With a supporting index, these rewrites let SQL Server seek.
An index stores the raw column values, not the result of a function applied to them. When you wrap a column in a function, SQL Server cannot match the function's output against the index, so it must compute the function for every row and scan the whole structure. Removing the function from the column restores the engine's ability to seek the index.
Primary sources & further reading
- Brent Ozar — Non-SARGable Predicates.
- SQLShack — How to use SARGable expressions in T-SQL queries.
- SQLServerCentral — SQL Server: SARGability.
Find the scans hiding in your procedures
SprocOptimizer spots non-SARGable predicates from a captured workload, proposes index-friendly rewrites, and validates them for identical results — on-premises, with no row-level data leaving your network.
Request a Demo Read the Optimization Guide