A production system started timing out. The stored procedure ran fine in SSMS — under 1 second, every time. But through the .NET API? 30–120 seconds. Timeouts. Errors. No CPU spikes. No blocking. No infrastructure alerts. The DBA checked. The infrastructure team checked. Nothing. So what changed? ━━━ The investigation ━━━ The timeline had one clue: the degradation started right after routine DBA maintenance — a statistics update and index rebuild. That narrowed it down. The maintenance invalidated the execution plan cache. SQL Server was forced to recompile the procedure on the next call. But why was SSMS fast and the API slow — on the exact same query? The answer was hiding in a DMV: ↳ sys.dm_exec_cached_plans showed TWO cached plans for the same stored procedure. ↳ Same query. Same parameters. Two completely different execution strategies. One had ~50 logical reads. The other had ~85,000. ━━━ The root cause ━━━ SQL Server uses a bitmask of SET options as part of the plan cache key.…