Reports and screens that were acceptable yesterday are slow today, with no change to the code.
Why this happens
Fresh statistics can produce a different execution plan. Usually that is an improvement; occasionally it is much worse, and it happens without anything in the application changing — which is why the timing is the strongest clue you have.
What to check
- When the statistics were last gathered, against when the slowdown started. If they coincide, you have your cause.
- Whether the plan changed for the specific statement, rather than assuming it did.
- Whether one statement is slow or everything is. Everything slowing points at the system — memory pressure, a full filesystem, a failing disk — not at a plan.
- Whether a large data change preceded it. A month-end load can shift a table's shape enough that both the old and new plans are wrong for it.
Care required
Reverting statistics or pinning a plan are both real options and both have consequences beyond the one query. Neither belongs in a production database on a hunch — establish the plan change first.
If none of the above explains it, raise a ticket and include what you checked. Reading this article cost you no hours.