SQL Server Performance Tuning Tips

Database is the most important and powerful part of any application. If your database is not working properly and taking long time to compute the result, this means something is going wrong in database. Here, database tune up is required, otherwise performance of the application will degrade.

Image may be NSFW.
Clik here to view.

I know a lot of articles already published on this topic. But in this article, I tried to provide a list of database tune up tips that will cover all the aspects of database. Database tuning is a very critical and fussy process. It is true that database tuning is a database admin task but we should have the basic level of knowledge for doing this. Because, if we are working on a project where there is no role of admin, then it is our responsibility to the maintain the performance of the database. If performance of database is degraded, then it will cause worst effect on the whole system. In this article, I will explain some basic database tuning tips that I learned from my experience and from my friends who are working as database administrator. Using these tips, you can maintain or upgrade the performance of your database system. Basically, these tips are written for SQL Server but we can implement these into another databases too, like Oracle and mysql. Please read these tips carefully and at the end of article, let me know if you find something wrong or incorrect.

Avoid Null value in fixed length field

We should avoid the Null value in fixed length fields because if we insert the NULL value in a fixed length field, then it will take the same amount of space as the desired input value for that field. So, if we require a null value in a field, then we should use a variable length field that takes lesser space for NULL. The use of NULLs in a database can reduce the database performance, especially, in WHERE clauses. For example, try to use varchar instead of char and nvarchar. NeveruseSelect*Statement:

When we require all the columns of a table, we usually use a “Select *” statement. Well, this is not a good approach because when we use the “select *” statement, the SQL Server converts * into all column names before executing the query, which takes extra time and efforts. So, always provide all the column names in the query instead of “select *”.

Normalize tables in database

Normalized and managed tables increase the performance of a database. So, always try to perform at least 3rd normal form. It is not necessary that all tables requires 3NF normalization form, but if any table contains 3NF form normalization, then it can be called well structured tables.

Keep Clustered Index Small

Clustered index stores data physically into memory. If the size of a clustered index is very large, then it can reduce the performance. Hence, a large clustered index on a table with a large number of rows increases the size significantly. Never use an index for frequently changed data because when any change in the table occurs, the index is also modified, and that can degrade performance.

Use Appropriate Data type

If we select inappropriate data type, it will reduce the space and enhance the performance; otherwise, it generates the worst effect. So, select an appropriate data type according to the requirement. SQL contains many data types that can store the same type of data but you should select an appropriate data type because each data type has some limitations and advantages upon another one.

Store image path instead of image itself

I found that many developers try to store the image into database instead of the image path. It may be possible that it is requirement of application to store images into database. But generally, we should use image path, because storing image into database increases the database size and reduces the performance.

USE Common Table Expressions (CTEs) instead of Temp table

We should prefer a CTE over the temp table because temp tables are stored physically in a TempDB which is deleted after the session ends. While CTEs are created within memory. Execution of a CTE is very fast as compared to the temp tables and very lightweight too.

Use Appropriate Naming Convention

The main goal of adopting a naming convention for database objects is to make it easily identifiable by the users, its type, and purpose of all objects contained in the database. A good naming convention decreases the time required in searching for an object. A good name clearly indicates the action name of any object that it will perform. *tblEmployees//Nameoftable *vw_ProductDetails//NameofView *PK_Employees//NameofPrimaryKey

Use UNION ALL instead of UNION

We should prefer UNION ALL instead of UNION because UNION always performs sorting that increases the time. Also, UNION can't work with text datatype because text datatype doesn't support sorting. So, in that case, UNION can't be used. Thus, always prefer UNION All.

Use Small data type for Index

It is very important to use Small data type for index . Because, the bigger size of data type reduces the performance of Index. For example, nvarhcar(10) uses 20 bytes of data and varchar(10) uses 10 bytes of the data. So, the index for varhcar data type works better. We can also take another example of datetime and int. Datetime data type takes 8 Bytes and int takes 4 bytes. Small datatype means less I/O overhead that increases the performance of the index. UseCount(1)insteadofCount(*)andCount(Column_Name):

There is no difference in the performance of these three expressions; but, the last two expressions are not good considered to be a good practice. So, always use count(10) to get the numbers of records from a table.

Use Stored Procedure

Instead of using the row query, we should use the stored procedure because stored procedures are fast and easy to maintain for security and large queries.

Use Between instead of In

If Between can be used instead of IN , then always prefer Between . For example, you are searching for an employee whose id is either 101, 102, 103 or 104. Then, you can write the query using the In operator like this: Select*FromEmployeeWhereEmpIdIn(101,102,103,104)

You can also use Between operator for the same query.

Select*fromEmployeeWhereEmpIdBetween101And104

Use If Exists to determine the record

It has been seen many times that developers use "Select Count(*)" to get the existence of records. For example Declare@Countint; Set@Count=(Select*FromEmployeeWhereEmpNameLike'%Pan%') If@Count>0 Begin //Statement End

But, this is not a proper way for such type of queries. Because, the above query performs the complete table scan, so you can use If Exists for same query. That will increase the performance of your query, as below.

IFExists(SelectEmp_NameFromEmployeeWhereEmpNameLike'%Pan%') Begin //Statements End

Never Use ” Sp_” for User Define Stored Procedure

Most programmers use “sp_” for user-defined Stored Procedures. I suggest to never use “sp_” for user-defined Stored Procedure because in SQL Server, the master database has a Stored Procedure with the "sp_" prefix. So, when we create a Stored Procedure with the "sp_" prefix, the SQL Server always looks first in the Master database, then in the user-defined database, which takes some extra time.

Practice to use Schema Name

A schema is the organization or structure for