Why Logical Reads Are A Bad Metric For Query Tuning In SQL Server

Why Logical Reads Are A Bad Metric For Query Tuning In SQL Server

To summarize the video a little bit:

  • High average or total logical reads isn’t a guarantee that a query is slow
  • Looking for high average CPU and duration queries is a better metric
  • You may see logical reads go up or down as you make queries faster
  • For I/O bound workloads, you’re better off looking for queries with a lot of physical reads

The more query tuning work I did, the more I came to realize that logical reads fall into the SQL Server 2008 mindset, like PLE, fragmentation, page splits, and other metrics that don’t necessarily indicate a performance problem.

Thanks for watching!

Going Further

If this is the kind of SQL Server stuff you love learning about, you’ll love my training. I’m offering a 75% discount to my blog readers if you click from here. I’m also available for consulting if you just don’t have time for that, and need to solve database performance problems quickly. You can also get a quick, low cost health check with no phone time required.

4 thoughts on “Why Logical Reads Are A Bad Metric For Query Tuning In SQL Server

  1. “Count the clock that tells the time” is the best advice I ever read. Harlan Ellison should have been a performance tuner. Instead he turned out to be a great writer, an irritating SOB and a fantastic role model for idiots like myself.

    I always count what the user experiences because they’re my customer.

    PS: Billy Shakespere wrote much the same this that was even before punch card so maybe he was just a few hundred years early.


      1. Picking books up is kind of necessary if you intend to put it down with great force. Especially on an empty cranium.

        But Harlan could churn out short stories that cut right to the point for those with short attention spans.

        How about an audio production of one of his stories?

Comments are closed.