SQL Server Parameter Sniffing: How to Find and Fix Slow Queries

A SQL Server query may run quickly for one set of parameters and become extremely slow for another. The query text has not changed, the database is still online, and the application may not have received any code updates. Yet users experience different response times when executing what appears to be the same operation.

One possible cause is parameter sniffing.

SQL Server uses parameter values during query compilation to help choose an execution plan. That plan can then be reused for later executions of the same parameterized query. When the initial values represent an unusual portion of the data, the selected plan may perform poorly for other values.

Parameter sniffing is not always a problem. It often helps SQL Server generate efficient execution plans. The problem occurs when a cached plan works well for some parameter values but poorly for others.

This article explains how parameter sniffing works, how to identify it, and which solutions are appropriate for different workloads.

What Is Parameter Sniffing?

Consider a stored procedure that retrieves orders for a customer:

CREATE OR ALTER PROCEDURE dbo.GetCustomerOrders
    @CustomerId INT
AS
BEGIN
    SET NOCOUNT ON;

    SELECT
        OrderId,
        CustomerId,
        OrderDate,
        TotalAmount
    FROM dbo.Orders
    WHERE CustomerId = @CustomerId;
END;

Suppose the Orders table contains millions of rows. Some customers have only a few orders, while others have hundreds of thousands.

When SQL Server compiles the stored procedure, it can use the supplied parameter value and available statistics to estimate how many rows the query will return. Based on that estimate, it selects an execution plan.

For a customer with a few orders, an index seek followed by a small number of lookups may be efficient. For a customer with a very large number of orders, scanning a larger portion of the table or index may be more efficient.

If SQL Server compiles the procedure using a customer with very few orders and then reuses that plan for a customer with hundreds of thousands of orders, the second execution may be much slower than expected.

This is one way parameter sniffing can cause performance problems.

The reverse can also happen. A plan compiled for a customer with many orders may perform unnecessary work when the procedure is called for a customer with only a few records.

How to Identify Parameter Sniffing

Do not assume that every slow query is caused by parameter sniffing. Missing indexes, outdated statistics, blocking, inefficient joins, and excessive I/O can produce similar symptoms.

Look for evidence that the same query performs differently depending on its parameter values.

Compare execution times for different parameters

Run the stored procedure using values that represent different data distributions:

EXEC dbo.GetCustomerOrders @CustomerId = 10;

EXEC dbo.GetCustomerOrders @CustomerId = 5000;

These values are examples. Use actual customer IDs from your database that return significantly different numbers of rows.

Compare the elapsed time, logical reads, CPU usage, and number of rows returned.

You can enable I/O and timing statistics in SQL Server Management Studio:

SET STATISTICS IO ON;
SET STATISTICS TIME ON;

EXEC dbo.GetCustomerOrders @CustomerId = 10;

EXEC dbo.GetCustomerOrders @CustomerId = 5000;

SET STATISTICS IO OFF;
SET STATISTICS TIME OFF;

STATISTICS IO reports information about data access, while STATISTICS TIME reports CPU and elapsed time.

A large difference between executions is a useful clue, but it is not proof of parameter sniffing. Different parameter values may naturally require different amounts of work.

Inspect the actual execution plan

In SQL Server Management Studio, enable the actual execution plan before running the stored procedure.

Look for these warning signs:

A large difference between estimated and actual row counts.
Expensive key lookups repeated many times.
An index seek that reads a large number of rows.
A scan that processes far more data than expected.
Large memory grants or spills to temporary storage.
Join algorithms that perform poorly for the actual row counts.

For example, an index seek may look efficient because it starts from a specific customer ID. However, if that customer has hundreds of thousands of orders, the seek may still return a very large result set and trigger many additional lookups.

The execution plan must be evaluated in the context of the actual number of rows and the work performed.

Check Query Store

Query Store records query performance information and execution plans over time. It is useful when a query becomes slow in production but works normally during a manual test.

If Query Store is enabled, inspect the query's execution history and look for differences in duration, CPU time, logical reads, and plan IDs.

A query that previously ran quickly and later became slow after a plan change deserves investigation. If the same query has multiple plans with different performance characteristics, plan selection may be contributing to the problem.

Query Store can also help identify whether the slowdown coincides with a deployment, a statistics update, a change in data distribution, or a different plan being selected.

Why SQL Server Reuses Execution Plans

Compiling a query requires work. SQL Server can cache an execution plan and reuse it when later requests execute the same eligible query.

This avoids repeatedly compiling the same statement.

Parameterized queries and stored procedures are common examples. When SQL Server compiles a parameterized statement, the parameter values available at compilation can influence cardinality estimates and plan selection.

The cached plan may remain useful for many executions. However, the data distribution may make one plan unsuitable for all parameter values.

For example:

Parameter value	Expected result size	Potentially suitable strategy
Customer with few orders	Small	Index seek with limited lookups
Customer with many orders	Large	Scan or a different access strategy
Customer with no orders	Empty	Minimal data access

These are illustrative possibilities, not guaranteed plan choices. SQL Server's optimizer considers indexes, statistics, row estimates, query structure, and other factors when selecting a plan.

Fix 1: Update Statistics When Estimates Are Incorrect

SQL Server uses statistics to estimate how many rows a query will return. If those estimates are inaccurate, the optimizer may select an unsuitable plan.

Check whether the relevant statistics are current and whether the data distribution has changed significantly.

You can update statistics for a table:

UPDATE STATISTICS dbo.Orders;

You can also update a specific statistic if you have identified which one is relevant:

UPDATE STATISTICS dbo.Orders
    IX_Orders_CustomerId;

The statistic name in the second example must match an existing statistic in your database.

Updating statistics can improve cardinality estimates and may lead SQL Server to choose a better execution plan. However, it does not guarantee that parameter sniffing will disappear. If one query must serve parameter values with very different data distributions, a single cached plan may still be unsuitable for some executions.

Statistics updates can also trigger recompilation and consume resources, so avoid scheduling unnecessary updates without understanding the workload.

Fix 2: Use OPTION (RECOMPILE)

When the best plan depends heavily on the current parameter values, recompiling the statement can be an effective solution.

CREATE OR ALTER PROCEDURE dbo.GetCustomerOrders
    @CustomerId INT
AS
BEGIN
    SET NOCOUNT ON;

    SELECT
        OrderId,
        CustomerId,
        OrderDate,
        TotalAmount
    FROM dbo.Orders
    WHERE CustomerId = @CustomerId
    OPTION (RECOMPILE);
END;

With OPTION (RECOMPILE), SQL Server compiles a plan for that statement when it executes, using the current parameter values and available optimization information.

This can produce a better plan for each execution when the number of matching rows varies significantly.

The trade-off is compilation overhead. If the statement runs thousands of times per second, recompiling it on every execution may consume substantial CPU.

Use this option when the benefit of parameter-specific plans outweighs the compilation cost. Measure the result under realistic load rather than assuming recompilation is always faster.

Fix 3: Use OPTIMIZE FOR

Sometimes you know that a particular parameter value represents a typical workload. SQL Server allows you to direct optimization toward a selected value.

CREATE OR ALTER PROCEDURE dbo.GetCustomerOrders
    @CustomerId INT
AS
BEGIN
    SET NOCOUNT ON;

    SELECT
        OrderId,
        CustomerId,
        OrderDate,
        TotalAmount
    FROM dbo.Orders
    WHERE CustomerId = @CustomerId
    OPTION (OPTIMIZE FOR (@CustomerId = 100));
END;

In this example, SQL Server optimizes the statement as though the parameter value were 100.

The actual execution still uses the supplied @CustomerId value. The hint influences plan optimization; it does not force the query to return data for customer 100.

This approach can help when a representative value produces a plan that performs well for most executions.

However, it can make performance worse if the workload changes or the selected value is not representative. Review parameter distributions before applying this hint.

You can also use OPTIMIZE FOR UNKNOWN when you want optimization to use average-distribution estimates rather than relying on a specific parameter value:

SELECT
    OrderId,
    CustomerId,
    OrderDate,
    TotalAmount
FROM dbo.Orders
WHERE CustomerId = @CustomerId
OPTION (OPTIMIZE FOR UNKNOWN);

This may produce a more balanced plan for some workloads, but it can also produce a poor plan when average estimates do not represent the important parameter values.

Fix 4: Use SQL Server 2022 Parameter Sensitive Plan Optimization

SQL Server 2022 introduced Parameter Sensitive Plan optimization, commonly called PSP optimization. It can help eligible parameterized queries that need different execution plans for different ranges of parameter values.

Instead of relying on one plan for every parameter value, SQL Server can maintain a dispatcher plan and multiple query variants for eligible queries. The dispatcher routes executions to an appropriate variant based on parameter cardinality ranges.

This can reduce the need for manual hints or separate versions of a query.

PSP optimization has prerequisites, including database compatibility level 160 for SQL Server 2022, and it applies only to eligible queries. It does not solve every parameter-sensitive workload.

Check the database compatibility level:

SELECT
    name,
    compatibility_level
FROM sys.databases
WHERE name = DB_NAME();

If the database is running at an older compatibility level, changing it may affect other query plans and application behavior. Test compatibility-level changes in a non-production environment before applying them to a production database.

For SQL Server versions and configurations that support PSP optimization, use Query Store and execution-plan information to verify whether a query is benefiting from multiple plan variants.

Fix 5: Consider Separate Query Paths

Sometimes two parameter groups require fundamentally different query strategies. In that case, separate query paths may be easier to understand and maintain than forcing one plan to serve both cases.

For example, a procedure might handle a special, well-defined business case separately from the general workload.

However, avoid using arbitrary thresholds without evidence. A rule such as "use one query for IDs below 1000 and another for IDs above 1000" is unlikely to be meaningful unless it corresponds to a real difference in data distribution or business behavior.

If separate paths are justified, test both with representative data and ensure that future changes in the dataset do not make the branching logic ineffective.

Common Mistakes When Fixing Parameter Sniffing

Clearing the entire plan cache

Clearing the plan cache can force SQL Server to compile new plans, but it affects more than the query you are investigating. It can temporarily increase CPU usage as plans are compiled again.

It also does not address the underlying reason that different parameter values need different plans.

Use targeted diagnosis and appropriate query-level solutions instead of clearing the entire plan cache as a routine fix.

Assuming a recompile always solves the problem

Recompilation can improve parameter-sensitive queries, but it introduces CPU overhead. It may also fail to solve the real issue if the query has missing indexes or inaccurate statistics.

Measure both query performance and compilation overhead.

Adding indexes without checking the plan

An index may reduce data access for one parameter value while increasing the cost of writes or making other queries less efficient.

Inspect the execution plan, examine the existing indexes, and validate any index change with realistic workloads.

Testing only one parameter value

A plan that performs well for a small customer may perform poorly for a customer with many orders.

Test parameter values representing the important parts of the data distribution, including unusually large result sets.

A Practical Troubleshooting Workflow

When a query is unexpectedly slow, follow a repeatable process:

Identify the exact query or stored procedure and the parameter values associated with the slowdown.
Compare duration, CPU time, logical reads, and actual row counts for representative parameter values.
Inspect actual execution plans and compare estimated versus actual rows.
Review Query Store for plan changes and historical performance.
Check statistics, indexes, data distribution, and other possible causes.
Test an appropriate fix, such as a statistics update, a query hint, or PSP optimization where supported.
Validate the result under realistic load and confirm that other parameter values have not become slower.

Do not make a production change based only on a single execution. A useful fix should improve the relevant workload without creating a larger performance problem elsewhere.

Conclusion

SQL Server parameter sniffing occurs when parameter values used during query compilation influence a cached plan that performs poorly for later executions. The feature itself is useful because plan reuse reduces compilation work, but uneven data distributions can make one plan unsuitable for every execution.

Use execution plans, runtime statistics, and Query Store to identify the actual cause before changing the query. Updating statistics, using OPTION (RECOMPILE), applying OPTIMIZE FOR, and using Parameter Sensitive Plan optimization are possible solutions, depending on the workload and SQL Server version.

The best fix is the one that performs reliably across representative parameter values while keeping compilation costs, database load, and maintenance complexity under control.