Question

I have a query that I have been tuning for some time but I can’t seem to get the execution time down much. In the execution plan everything looks like it is doing what it is supposed to, no large costs associated with any particular part of the query, everything is using index seek where it is supposed to. When I run the same query against a different client it runs fairly quickly but only returns 150k records. When I run it for my biggest client it returns 600k records and takes over ten minutes.

Could my issue be that with the number of records I’m returning it will be hard to get good performance or does what I described above seem within the ability of SQL Server?

Answer 1

Besides the number of records, what else is different on between the two systems:

• RAM available for SQL
• CPU cores
• IO configuration (number of spindles in RAID, type of RAID, configuration of the LUN)
• IO path (layout of logical and physical disks, location of database mdf/ndf/ldf files)
• index fragmentation
• load on the SQL Server
• load on the host machine

When compared the two locations for SET STATISTICS IO ON:

• does the 600k do about x4 times IO compared with the 150k location? Then the time difference can be entirely attributed to the differences in hardware.
• Is the logical IO count on the lines of x4 times but the physical IO count differ wildly? Then you have a RAM issues (not enough to cache the database in memory).
• Is the number of physical IOs close to the expected x4 times, but the time is very different? Then you are probably dealing with fragmentation.
• Does the number of IOs differ significantly from the expected x4 times? Then you have a different plan probably driven by very different cardinality and estimates.

These are, of course, wild shots in the dark without proper data to back them up. Consider them a guess, not an authorithative solution.