Microsoft's October 17, 2026 Azure Database Support case study starts with a familiar complaint: a stored procedure is fast in another environment. Its investigation shows why matching the query, indexes, and runtime parameter is not enough to establish an equivalent execution. Lessons Learned #561.
This is fresh troubleshooting guidance, not a new Azure SQL feature. The practical opportunity is to improve the evidence collected before somebody changes an index, clears cached plans, or scales the service.
What Microsoft's Demonstration Found
Both measured executions used the same runtime parameter, but the cached plans had been compiled for different customers. The slower plan estimated 100 matching rows and processed 500,000, repeatedly performing Key Lookups. Logical reads were 1,532,129, compared with 30,418 in the faster execution. Both reported zero physical reads. Published measurements.
The case used recompilation diagnostically, then extended an index to cover the required value. It also checked whether Parameter Sensitive Plan optimization participated instead of assuming that enabling it meant it intervened. These are results from Microsoft's demonstration, not measurements of your workload. Investigation and conclusions.
Preserve the Comparison Before Changing It
My first recommendation is to capture an evidence pair that another engineer can interpret: the exact procedure or statement, runtime inputs, execution timestamp, actual plan, and associated performance observations for each side.
Label the environment and execution clearly. Avoid combining one run's plan with another run's duration simply because both files came from the same server.
Also record the conditions the team considers equivalent: relevant data, schema, database configuration, and application call pattern. Treat any unknown as an open question rather than filling the gap with an assumption.
Do this before a remedial change removes the original behavior. The immediate objective is an explainable comparison, not a collection of screenshots from different stages of an incident.
Separate More Work from More Waiting
Microsoft's broader two-server troubleshooting guide distinguishes increased computational work from waiting and environmental differences. It also notes that parallel execution complicates simple CPU-versus-elapsed-time comparisons. That guide is scoped to SQL Server; review platform-specific tooling and permissions when applying the approach to Azure SQL.
For an Azure SQL review, I would put duration, CPU, logical reads, relevant waits, and plan observations together in the same incident record. Ask which evidence explains the extra elapsed time rather than treating every slow result as a capacity problem.
If repeated lookups dominate the work, investigate why that shape was chosen. If the work looks comparable but completion takes longer, investigate the observed wait conditions. Keep those as hypotheses until the captured evidence supports them.
Inspect Compilation History, Not Just Today's Input
My plan-review checklist would include estimated versus actual rows at the important operators, compiled and runtime parameter values where available, and how often expensive operators executed.
Do not declare parameter sensitivity solely because two parameter values differ. Connect that observation to the execution behavior that matters: inaccurate estimates, a costly access pattern, and repeatable consequences for representative inputs.
A useful incident note should explain that chain in ordinary language. The next engineer should understand why the proposed experiment tests the hypothesis, not just which option was selected in a tuning tool.
Validate a Fix Across the Application's Inputs
For a controlled follow-up, I would reproduce the relevant call sequence in an approved test environment and vary the representative input groups. Retain both the initial evidence and the changed result.
An improvement for the largest customer is not enough if smaller, frequent calls regress. Define acceptable behavior for the workload before deciding that the experiment succeeded.
Evaluate an index change against its wider operational impact and agree on a reversal plan. Treat recompilation as an experiment to interpret, not an automatic instruction to recompile every production execution.
Practical Cloud Engineer Takeaway
Capture matched evidence before modifying the environment.
Compare work and waits alongside duration.
Review compiled parameters as well as runtime inputs.
Verify whether an optimization actually participated.
Test the proposed fix across representative call sequences.
Who Should Care?
Azure SQL administrators, application engineers, and incident responders investigating performance differences that are not explained by a quick schema comparison.
Bottom Line
A faster environment is a comparison point, not a diagnosis. Establish what each execution actually did, then change the smallest thing that tests your explanation.
No database, index, plan cache, service tier, or configuration was changed for this article. The numerical results above belong to Microsoft's published case.
Sources
Stay radical, stay curious, and keep pushing the boundaries of what is possible in the cloud.
Chriz
Beyond Cloud with Chriz
Comments