1: Restarting the server... without identifying the cause
This is the first thing many teams try. “Let's restart SQL Server, it'll start working again.” Sometimes it works... temporarily. And that's the problem.
Why this is a mistake
Restarting removes the symptoms without fixing the problem. You lose the cache contents, compiled plans, and traces that are useful for analysis. It's like restarting a car that's making a strange noise... without opening the hood.
What to do
Before restarting, take the time to capture the server's status: active queries, blockages, response times. SQL Server offers several simple tools for this (Activity Monitor, DMVs, Query Store, Extended Events, etc.). With the right information, you can make a real diagnosis of the server's status, rather than just hoping that restarting will miraculously fix everything.
2: Targeting the source code... without proof
Another classic: “It must be Marc's query that's causing everything to crash.” And now the developer has to spend hours reviewing code that may not be at fault.
Why this is a mistake
Without metrics, you're just guessing. The problem may be due to a change in data, a modified execution plan, or a lack of indexes... and not the code itself. Without accurate data, any optimization is blind.
What to do
Start by identifying which query is causing the slowdown, using tools such as sys.dm_exec_query_stats, Query Store, or recent execution plans. Once the problem has been identified, the developer will know where to focus their efforts and you will save time on both sides.
3: Add an index... just to try it out!
It's tempting: “What if we put an index here... just to see?”
But be careful: a poorly placed or unnecessary index can degrade performance elsewhere.
Why it's a mistake
One more index means more data to maintain during inserts or updates. And the more there are, the more likely the optimizer is to make mistakes. By accumulating “test” indexes, you create silent conflicts.
What to do
Analyze the execution plan to identify the problematic table and the costly operation. If an index is necessary, it should target a specific query and, ideally, cover the right columns. It's better to learn how to read a basic execution plan than to stack indexes at random. You'll save time... and improve performance.
4: Wrongly blaming scheduled tasks
Is a scheduled process slowing down the application? “It must be the 2 a.m. cleanup job.” And so a critical process is canceled... without certainty.
Why this is a mistake
Some jobs are there for a good reason: to update statistics, clean up histories, reindex. Cutting these tasks can make the situation worse in the long run.
What to do
Check the exact schedule of the jobs, their duration, and their actual impact on resources (CPU, I/O, locks). Sometimes, all you need to do is reschedule intelligently or reduce the load (e.g., sampling stats instead of a full scan). Don't shoot the messenger!
5: Waiting for it to pass...
This is the quietest mistake. No one takes action, we adapt, we wait... and over time, slowness becomes the norm.
Why it's a mistake
The degradation is gradual, and therefore insidious, but the costs are very real: loss of productivity, team frustration, and decreased confidence in IT. Slow degradation hurts productivity and stability.
What to do
Act at the first signs. Have a minimum of monitoring (response time, slow queries, index growth, TempDB file size, etc.). Even without a budget or sophisticated tools, a few well-placed scripts can make a huge difference.
The real problem is uncertainty.
What hurts performance the most is not knowing where the slowness is coming from. When everything slows down, it's not always SQL, it's not always the application, and it's never a good idea to try to guess. The good news is that there is a simple, structured approach to making the right diagnosis, even if you're not an expert with 20 years of experience. Approaching the problem with structure, capturing the right metrics, and using the right tools is what really makes the difference.
I'll be discussing this topic in detail in the upcoming webinar, “SQL Server or the application: the real culprit behind performance.”
Need to go beyond the basics and explore real optimizations?
