Here are fourteen little known tips that you can use to ensure your Transact-SQL queries are performing in the most efficient manner possible.
1. Try to restrict the queries result set by using the WHERE clause.
This can result in a performance benefit, as SQL Server will
return to the client only particular rows, not all rows from the table(s).
This can reduce network traffic and boost the overall performance of
the query.
2. Try to restrict the queries result set by returning only the
particular
columns from the table, not all the table’s columns.
This can result in a performance benefit as well, because SQL Server will
return to the client only particular columns, not all the table’s columns. This
can reduce network traffic and boost the overall performance of the
query.
3. Use views and stored procedures instead of heavy-duty queries.
This can reduce network traffic as your client will send to the server
only stored procedures or view name (perhaps with some parameters) instead
of large heavy-duty queries text. This can be used to facilitate
permission
management also, because you can restrict user access to table columns
they should not see.
4. Whenever possible, try to avoid using SQL Server cursors.
SQL Server cursors can result in some performance degradation in
comparison
with select statements. Try to use correlated subquery or derived tables,
if
you need to perform row-by-row operations.
5. If you need to return the total table’s row count, you can use
an alternative way instead of the SELECT COUNT(*) statement.
Because the SELECT COUNT(*) statement makes a full table scan to return the
total table’s row count, it can take an extremely long time for large tables.
There is another way to determine the total row count in a table. In this case, you can
use the sysindexes system table. There is a ROWS column in the
sysindexes table. This column contains the total row count for each table
in your database. So, you can use the following select statement instead
of SELECT COUNT(*):
SELECT rows FROM sysindexes WHERE id = OBJECT_ID('table_name') AND indid <
2
This way, you can improve the speed of such queries by several times. See this article for more details:
Alternative
way to get the table's row count.
6. Try to use constraints instead of triggers, whenever possible.
Constraints are much more efficient than triggers and can boost
performance.
So, whenever possible, you should use constraints instead of triggers.
7. Use table variables instead of temporary tables.
Table variables require fewer locking and logging resources than temporary
tables, so table variables should be used whenever possible. The table
variables are available in SQL Server 2000 only.
8. Try to avoid the HAVING clause, whenever possible.
The HAVING clause is used to restrict the result set returned by the GROUP
BY
clause. When you use GROUP BY with the HAVING clause, the GROUP BY clause
divides the rows into sets of grouped rows and aggregates their values,
and then the HAVING clause eliminates undesired aggregated groups. In many
cases, you can write your select statement so that they will contain only
WHERE and GROUP BY clauses without the HAVING clause. This can improve the
performance of your query.
9. Whenever possible, try to avoid using the DISTINCT clause.
Because using the DISTINCT clause will result in some performance
degradation, you should use this clause only when it is absolutely necessary.
10. Include SET NOCOUNT ON statement into your stored procedures to stop
the message indicating the number of rows affected by a T-SQL
statement.
This can reduce network traffic, as your client will not receive
the message indicating the number of rows affected by a T-SQL
statement.
11. Use select statements with the TOP keyword or the SET ROWCOUNT
statement if you need to return only the first n rows.
This can improve performance of your queries, as a smaller result
set
will be returned. This can also reduce the traffic between the server and
the clients.
12. Use the FAST number_rows table hint if you need to quickly return
'number_rows' rows.
You can quickly get the n rows and can work with them when the query
continues execution and produces its full result set.
13. Try to use UNION ALL statement instead of UNION, whenever
possible.
The UNION ALL statement is much faster than UNION, because UNION ALL
statement does not look for duplicate rows, while the UNION statement
does look for duplicate rows, whether they exist or not.
14. Do not use optimizer hints in your queries.
Because the SQL Server query optimizer is very clever, it is highly unlikely
that you can optimize your query by using optimizer hints; more often than not,
this will hurt performance.
