1

I have a query that is running slowly. I know generally to make performance faster, limit joins, and try to use procs instead of straight queries. Due to business rules, I cannot use procs. I've already cut the number of joins as much as I can think of.

What's the next step in query tuning?

Pulsehead
  • 5,050
  • 9
  • 33
  • 37
  • Query tuning is a very large field, and it's impossible to tell from what you've written how adept you are in it. It would be better if you were to put a sample query up and tell us in detail what you've tried. I even have no idea whether you've even thought of indexes, or whether you've measured performance with all reasonable indexes and are still puzzled. – David Thornley Aug 24 '10 at 15:07
  • 1
    Cutting the joins is not a good idea if the data returned is differnt. This is not generally a good way to performance tune as you usually lose information. – HLGEM Aug 24 '10 at 15:08
  • [SET SHOWPLAN_ALL](http://msdn.microsoft.com/en-us/library/ms187735.aspx) –  Mar 17 '14 at 16:30

2 Answers2

3

Adding indexes is probably the number one thing you can do to improve query performance and you haven't mentioned it.

Have you looked at the execution plan to see whether that could be improved with additional indexes?

Additionally you should make sure that your queries are written in such a way so they can use any indexes that are present effectively (e.g. avoid non sargable constructs, avoid *)

Martin Smith
  • 438,706
  • 87
  • 741
  • 845
  • 1
    Also avoid row-by row processing which means get rid of correlated subqueries and cursors as much as possible. – HLGEM Aug 24 '10 at 15:07
  • 1
    Also many people forget to put indexes on the FKs in their system, PKs are automatically indexed, FKs are not. – HLGEM Aug 24 '10 at 15:09
2

the easiest thing to do is go to management studio run this command:

SET SHOWPLAN_ALL ON

then run your actual query.

You will not get your regular query result set. It will give you the execution plan (a very detailed list of what SQL Server does to turn your query) in a result set. Look over the output and try to learn what it means. I generally look for "SCAN", that is a slow part, and I try rewriting it so it uses an index.

KM.
  • 101,727
  • 34
  • 178
  • 212