Six scans, six logical reads. What could be the problem? There’s no problem if you’re always dealing with six rows of data. If you’re dealing with 6mm, however, this is likely to be a performance problem on your server. Many developers might write a query, check the statistics, and see something like that shown above, and think that it’s a good day’s work.
Solving the problem is only half the job you should do. Solving things in an efficient way is the other half. When you tackle a new T-SQL challenge, what’s your methodology? Do you have one? I don’t need to know, though if you think you have a good one, post a note in the discussion, or perhaps write an article. If you aren’t sure how you begin, other than randomly trying ideas you vaguely understand or have seen others try, perhaps you want to start by reading Kathi Kellenberger’s Step by Step method.
The image above comes from Kathi’s article, and is indeed the result of her first solution to a complex T-SQL problem. She lists out the basic steps she used to derive the solution, along with the business rules used. All too often I’ve found developers (including myself), start writing code without taking a few minutes to specifically state the business rules. Following that one step might eliminate lots of bugs in coding.
Her solution worked, but with 6 scans occurring on her 11 rows of data, she knew this would be an issue. Moving forward she asked for help, which is perfectly acceptable way of working in your career. Try to solve it yourself, get a solution working, and then ask if it can be improved. Not only did she end up with a better performing solution, but she learned a bit more along the way. Something we all can do.
The Voice of the DBA Podcasts
We publish three versions of the podcast each day for you to enjoy.