SQL server T-SQL best practice
This month’s TSQL Tuesday party is being hosted by Amit Banerjee (Blog | Twitter).
He is working in Microsoft and see here his online activities MSDN. The topic this month is T-SQL best practice. It’s the both DBA and developers Topic/Job.
Transact SQL is the best tool to improve the SQL server overall performance. You write your code efficiently then you no need to spend lots of money to buy extra hardware or RAM etc... So the coders/developers have to know the best practice. He or She does good job(writing correct codes) then, There is no work for the DBAs. There is lots of T-SQL best practice available on the Internet. Here I’m going to share mine. The first 15 bullet points are personally i have faced and tuned in my environment. I will have planned to write each posts for all 15 points with examples.
T-SQL best practice
DOs and Don’Ts
- Check/Validate your conditions out of the loop (While/If) statement.
- Specify correct data type size
Ask the customer and specify the correct data type size what they really need. Otherwise you will end up with problem when your data grow larger.
E.X
For inserting 4 digit character don’t create VARCHAR (400) just create VARCHAR (4)
- Always write a query using seek able operator in your WHERE clause.
- Try to avoid Functions and date time functions when you write Quires i.e. Sproc .
- Avoid an index hints
Use the index hint if you really know it’ll improve the performance otherwise avoids it.
SELECT * FROM emp WITH (INDEX(ix_n)) WHERE n ='server'
- Don’t create too much indexes.
Create the indexes it’s really useful otherwise don’t. I have seen a table have 5 non clustered indexes with mostly same column definitions for particular table/SP and the table size is 4 GB and the indexes size are nearly 9 GB.
- Don’t use wildcard character at the beginning of the word
Always write seekable codes.
SELECT ID FROM <table_name> WHERE NAME LIKE 'muthu%'
SELECT ID FROM <table_name> WHERE NAME LIKE '%kumar'
- Normalize your tables
The best design will give the best performance. Normalize your tables before going to your project. I.e. my second point (Specify correct data type size etc...)
- Try to write set based queries minimize iteration/Cursors as much as you can.
- Use joins instead of sub query
Use the joins instead of sub query it’ll give better performance.
SELECT * FROM TBL WHERE N IN (SELECT N FROM TBL1)
SELECT A.* FROM TBL A JOIN TBL1 B
ON (A.N=B.N)
- Use the batch statement if you’re going to delete huge number of records from the table
Write a batch statement if you’re going to delete huge records it’ll minimize the log file size. Most importantly inform to the DBA team before going to delete otherwise we will get a call from customer the DB has been down.
- Use ANSI-Standard Join clauses instead of the old style joins
SELECT e.no,ed.name
FROM employee e, employee_details ed,
WHERE ed.name ='muthu'
SELECT e.no,ed.name
FROM employee e INNER JOIN employee_details ed
ON emp.no=ed.no
WHERE ed.name ='muthu'
- Test your data and the indexes after migrating one server to another server especially 2000 to 2005/2008.
- Create a filter index if you know the query often fetch the unchanged data from a big table.
A well-designed filtered index can improve query performance, reduce storage costs, and reduce maintenance too.
CREATE NONCLUSTERED INDEX I_fi_test
ON dbo.test (ID,joinDate,Relievingdate)
WHERE joinDate > '2001/01/01';
- Use NO LOCK hint if you have no problem with dirty reads.
- Create a clustered index (Primary key) for all mostly used tables
Try to create a clustered index for all the tables. I had seen most of my big tables are not defragmented because of the tables are created primary key with NON clustered index. I asked reason they told we don't know who has created (If you really don't know tuning ask the DBA).
- Use SELECT 1 instead of SELECT *
Use SELECT 1 when you’re checking the records are available in your table.
IF EXISTS (SELECT 1 FROM <table_name> WHERE id=100)
- In general rule retrieve the columns as you want don’t use “SELECT *”
Write a required column in SELECT statement as you want don’t SELECT all the columns.
E.X
SELECT * FROM <table_name>
SELECT c1,c2 FROM <table_name>
- Don’t write your procedure name starting with “SP_”
SQL server searches all the producers one by one starting with “SP_” in the database including system procedure then finally found yours. It causes minor overhead.
- Use WHERE condition as much as possible
SELECT * FROM emp WHERE Name ='SERVER'
- Use TRY-Catch for error handling
See my procedure has written using TRY-Catch.
- Try to avoid dynamic SQL
It'll generate SQL injections if you're not write it effectively.
- Always write your codes/SProcs with descriptions and comments.
I hope this best practice will help for the developers/coders. Thanks to Amit has given this great topic.
