Few days ago, while searching for something on web site, I came across a very good article of 25 SQL Commandments. I really enjoyed reading it. It was for Oracle, I re-wrote it for SQL Server. First 18 points are taken from original article and last 2 I added to complete total of 20 Commandments. Many more rules and suggestions can be added to this list, this list is just a beginning.
1. Know your data and business application well.
Familiarize yourself with these sources; you must be aware of the data volume and distribution in your database.
2. Test your queries with realistic data.
A SQL statement tested with unrealistic data may behave differently when used in production. To ensure rigorous testing, the data distribution in the test environment must also closely resemble that in the production environment.
3. Write identical SQL statements in your applications.
Take full advantage of stored procedures, and functions wherever possible. The benefits are performance gain as they are precompiled.
4. Use indexes on the tables carefully.
Be sure to create all the necessary indexes on the tables. However, too many of them can degrade performance.
5. Make an indexed path available.
To take advantage of indexes, write your SQL in such a manner that an indexed path is available to it. Using SQL hints is one of the ways to ensure the index is used.
6. Understand the Optimizer.
Understand the optimizer how it uses indexes, where clause, order by clause, having clause, etc.
7. Think globally when acting locally.
Any changes you make in the database to tune one SQL statement may affect the performance of other statements used by applications and users.
8. The WHERE clause is crucial.
The following WHERE clauses would not use the index access path even if an index is available.
e.g. Table1Col1 (Comparision Operator like >, <, >=, <=,) Table1Col2, Table1Col1 IS (NOT) NULL, Table1Col1 NOT IN (value1, value2), Table1Col1 != expression, Table1Col1 LIKE ‘%pattern%’, NOT Exists sub query.
9. Use WHERE instead of HAVING for record filtering.
Avoid using the HAVING clause along with GROUP BY on an indexed column.
10. Specify the leading index columns in WHERE clauses.
For a composite index, the query would use the index as long as the leading column of the index is specified in the WHERE clause.
11. Evaluate index scan vs. full table scan. (Index Only Searches Vs Large Table Scan, Minimize Table Passes)
If selecting more than 15 percent of the rows from a table, full table scan is usually faster than an index access path. An index is also not used if SQL Server has to perform implicit data conversion. When the percentage of table rows accessed is 15 percent or less, an index scan will work better because it results in multiple logical reads per row accessed, whereas a full table scan can read all the rows in a block in one logical read.
12. Use ORDER BY for index scan.
SQL Server optimizer will use an index scan if the ORDER BY clause is on an indexed column. The following query illustrates this point.
13. Minimize table passes.
Usually, reducing the number of table passes in a SQL query results in better performance. Queries with fewer table passes mean faster queries.
14. Join tables in the proper order.
Always perform the most restrictive search first to filter out the maximum number of rows in the early phases of a multiple table join. This way, the optimizer will have to work with fewer rows in the subsequent phases of join, improving performance.
15. Redundancy is good in where condition.
Provide as much information as possible in the WHERE clause. It will help optimizer to clearly infer conditions.
16. Keep it simple, stupid.
Very complex SQL statements can overwhelm the optimizer; sometimes writing multiple, simpler SQL will yield better performance than a single complex SQL statement.
17. You can reach the same destination in different ways.
Each SQL may use a different access path and may perform differently.
18. Reduce network traffic and increase throughput.
Using T-SQL blocks over Multiple SQL statements can achieve better performance as well as reduce network traffic. Stored Procedures are better over T-SQL blocks as they are stored in SQL Server and they are pre-compiled.
19. Better Hardware.
Better hard ware always helps performance. SCACI drives, Raid 10 Array, Multi processors CPU, 64-bit operating system improves the performance by great amount.
20. Avoid Cursors.
Using SQL Server cursors can result in some performance degradation in comparison with select statements. Try to use correlated sub query or derived tables if you need to perform row-by-row operations.
Update: Few of this and other new commandments include here: Good, Better and Best Programming Techniques
Reference : Pinal Dave (https://blog.sqlauthority.com)
Thank you Sean,
That is absolutely true and thanks for pointing that out. Since SQL SERVER 2005, forced parameterization can improve performance of any external SQL request.
#3 is no longer true since SQL 7. SQL Server doesn’t precompile stored proceedures, and from 7 onward has extended caching to external SQL requests.
It’s in the manual and well documented across the web.
the commandents,u have written are very useful.
thanx a lot.
Its a very good stuff.
– Ramesh Gopalan
My Query is
i had changed the windows 2003 server name on which i had installed sql server 2000
now my sql server is not running
how to rename the sql server.
Your tips were very useful… I think, minimizing the use of Orderby, Min(), Max() etc, should also included.
Thanks & Regards
Sorry for asking a silly question. #13, table passes. What is that?
Thanks in support of sharing such a nice thinking, post is pleasant, thats why i have read it completely
Thanks Dave :) Very handy.
My pleasure Ferruccio.