Scribd
Upload
3 views

Query_Optimization

The document provides various SQL query optimization techniques, such as choosing appropriate data types, avoiding certain data types like nchar and nvarchar, and using EXISTS instead of IN for better performance. It emphasizes the importance of indexing, using JOINs over subqueries, and avoiding cursors for efficiency. Additionally, it suggests best practices like using schema names and avoiding the 'sp_' prefix for user-defined stored procedures.

Uploaded by

michaelnicolsamai8
Copyright
© © All Rights Reserved
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
3 views

Query_Optimization

The document provides various SQL query optimization techniques, such as choosing appropriate data types, avoiding certain data types like nchar and nvarchar, and using EXISTS instead of IN for better performance. It emphasizes the importance of indexing, using JOINs over subqueries, and avoiding cursors for efficiency. Additionally, it suggests best practices like using schema names and avoiding the 'sp_' prefix for user-defined stored procedures.

Uploaded by

michaelnicolsamai8
Copyright
© © All Rights Reserved
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 15

Query Optimization

Amit Kumar
Choose Appropriate Data Type
• Choose appropriate SQL Data Type to store your data since it also
helps in to improve the query performance. Example: To store strings
use varchar in place of text data type since varchar performs better
than text. Use text data type, whenever you required storing of large
text data (more than 8000 characters). Up to 8000 characters data
you can store in varchar.
Avoid nchar and nvarchar
• Practice to avoid nchar and nvarchar data type since both the data
types takes just double memory as char and varchar. Use nchar and
nvarchar when you required to store Unicode (16-bit characters) data
like as Hindi, Chinese characters etc.
Avoid * in SELECT statement
• Practice to avoid * in Select statement since SQL Server converts the
* to columns name before query execution. One more thing, instead
of querying all columns by using * in select statement, give the name
of columns which you required.
Use EXISTS instead of IN
• Practice to use EXISTS to check existence instead of IN since EXISTS is
faster than IN.
Create Clustered and Non-
Clustered Indexes
• Practice to create clustered and non clustered index since indexes
helps in to access data fastly. But be careful, more indexes on a tables
will slow the INSERT,UPDATE,DELETE operations. Hence try to keep
small no of indexes on a table.
Keep clustered index small
• Practice to keep clustered index as much as possible since the fields
used in clustered index may also used in nonclustered index and data
in the database is also stored in the order of clustered index. Hence a
large clustered index on a table with a large number of rows increase
the size significantly.
Avoid Cursors
• Practice to avoid cursor since cursor are very slow in performance.
Always try to use SQL Server cursor alternative.
Use Table variable inplace of
Temp table
• Practice to use Table varible in place of Temp table since Temp table
resides in the TempDb database. Hence use of Temp tables required
interaction with TempDb database that is a little bit time taking task.
Use UNION ALL in place of
UNION
• Practice to use UNION ALL in place of UNION since it is faster than
UNION as it doesn't sort the result set for distinguished values.
Use Schema name before SQL
objects name
• Practice to use schema name before SQL object name followed by "."
since it helps the SQL Server for finding that object in a specific
schema. As a result performance is best.
Avoid prefix "sp_" with user
defined stored procedure name
• Practice to avoid prefix "sp_" with user defined stored procedure
name since system defined stored procedure name starts with prefix
"sp_". Hence SQL server first search the user defined procedure in the
master database and after that in the current session database. This
is time consuming and may give unexcepted result if system defined
stored procedure have the same name as your defined procedure.
Use JOINs rather than
subqueries
• If possible (and if it makes sense), I suggest using JOIN statements
rather than subqueries to improve performance. When a subquery is
used as criteria in a SELECT statement, the values returned from the
subquery are distinct. Returning a distinct list of values requires
additional processing, which can slow down your queries.
Avoid correlated subqueries
A correlated subquery is one which uses values from the parent query.
This kind of query tends to run row-by-row, once for each row returned by the outer query,
and thus decreases SQL query performance. New developers are often caught structuring
their queries in this way—because it’s usually the easy route.

Here’s an example of a correlated subquery:


SELECT c.Name, c.City, (SELECT CompanyName FROM Company WHERE ID = c.CompanyID) AS CompanyName FROM Customer c

In particular, the problem is that the inner query


(SELECT CompanyName…) is run for each row returned by the outer query
(SELECT c.Name…). But why go over the Company again and again for every row processed by the outer query?

A more efficient performance tuning technique would be to refactor the correlated subquery as a join:
SELECT c.Name, c.City, co.CompanyName FROM Customer c LEFT JOIN Company co ON c.CompanyID = co.CompanyID

In this case, we go over the


Company table just once, at the start, and JOIN it with the Customer table. From then on, we can select the values we need (co.CompanyName) more efficiently.
THANK YOU

You might also like