Skip to content

This Week’s Episode: 4 Common Mistakes That May Be Affecting Your SQL Server Performance

Common SQL Mistakes

This week on the SQL Server Podcast, we dig into four common (but often overlooked) mistakes that could be dragging down your SQL Server performance. Whether you’re managing a small instance or supporting a complex enterprise environment, these are issues that show up more often than you’d expect. In this episode, I break down each one with real-world examples and guidance on how to fix or avoid them altogether.

Watch the episode on YouTube here: https://youtu.be/Ugrfh7HhkL8

Let’s take a quick look at what’s covered:

1. Misuse of Correlated Subqueries

Correlated subqueries have their place, but too often they’re used inappropriately, especially in reporting queries or batch update scenarios. When used incorrectly, these subqueries can lead to inefficient execution plans and major performance bottlenecks.

We look at examples where a simple rewrite using a JOIN or OUTER APPLY results in performance improvements of 10x or more. Understanding when a correlated subquery is appropriate—and when it’s not—is key to writing better T-SQL.

2. Overusing CROSS APPLY

CROSS APPLY is one of those powerful tools that, when used properly, can give you flexibility and performance gains. But overuse—or worse, misuse—can lead to inefficient plans, especially if the underlying function or subquery is expensive.

In the episode, I walk through a few real client scenarios where CROSS APPLY caused more harm than good and show how switching to a more appropriate construct reduced CPU usage dramatically.

3. Missing or Overlooked Indexes

This one might sound obvious, but missing indexes are still one of the most common problems we see in performance reviews. Sometimes, it’s not even a missing index—it’s an existing index that’s not being used because of poor query design or improper index hints.

We cover how to detect missing indexes (with help from Database Health Monitor) and how to interpret SQL Server’s index suggestions without blindly creating every one.

4. Overly Wide Tables

Tables with dozens or even hundreds of columns can cause unexpected issues—slower I/O, larger memory grants, increased tempdb usage, and painful performance problems in general. These tables often come from a “just add a column” design philosophy that snowballs over time.

In the podcast, I share some real-world examples of how reducing column widths, splitting tables, or simply rethinking the schema helped boost performance significantly.


If you’ve experienced any of these challenges—or want to make sure you never do—this episode is a must-listen. And remember, most SQL Server performance problems aren’t caused by a single bad query—they’re the result of small issues compounding over time.

That’s where our SQL Server Managed Services come in. With expert monitoring, fast support, and performance tuning built-in, we help teams avoid these kinds of problems before they ever impact production.

You can also get started with Database Health Monitor, our free tool that helps identify many of the issues discussed in this episode.

Listen now, and take the next step toward smoother, faster SQL Server performance.


Want to talk about your own SQL Server performance headaches? Contact us today—we’d love to help.


For other podcast platforms and episodes, here are some helpful links:

If you think you are encountering corruption in your database, don’t be afraid to reach out to the experts. We are here to help.

Don’t forget to check out our previous episodes from Season one!

If you’re ready to take your SQL Server performance to the next level, visit https://stedmansolutions.com/about-us/promotions/performance-assessment/sql-server-performance-consulting/ to learn more about our SQL Server Performance Consulting services.

 

More from Stedman Solutions:

SteveStedman5
Steve and the team at Stedman Solutions are here for all your SQL Server needs.
Contact us today for your free 30 minute consultation..
We are ready to help!

Leave a Reply

Your email address will not be published. Required fields are marked *

sixty eight − sixty =