Transact-SQL Optimization TipsJuly 9, 2002
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.
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.
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.
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.
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(*):
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.
Constraints are much more efficient than triggers and can boost
performance.
So, whenever possible, you should use constraints instead of triggers.
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.
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.
Because using the DISTINCT clause will result in some performance
degradation, you should use this clause only when it is absolutely necessary.
This can reduce network traffic, as your client will not receive
the message indicating the number of rows affected by a T-SQL
statement.
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.
You can quickly get the n rows and can work with them when the query
continues execution and produces its full result set.
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.
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.
|