SQL QUERY TUNING AND

SAFE PROCEDURE
WRITING
SUBMITTED BY: -
AMAN SHARMA
 INTRODUCTION
 Query tuning is really necessary nowadays for the
smoothness of production Database.
One of the most important activity of a Database
Administrator is to make well tuned ‘Stored
Procedures’. A Stored Procedure is a well prepared
SQL which you can save , so that code can be used
over and over again.
In this presentation I will provide the
Importance of SP and tips on making a good and
well executed Stored Procedure.
 TUNING OF SQL QUERY IN SP
• Keywords - Use SQL keywords in capital letters to increase readability. Also use proper indentation to
increase readability.
• Variables - Use as few as possible variables. It frees spaces in cache.
• SELECT statements - Try to use only the required number of columns in the SELECT clause instead of using
*. Using * returns all columns, which unnecessarily create a fat record set. Using the SELECT statement will
point the database to querying only the data you need to meet the business requirements. Here’s an example
where the business requirements request mailing addresses for customers.
Inefficient:
SELECT *
FROM Customers
This query may pull in other data also stored in the customer table, such as phone numbers, activity dates, and
notes from sales and customer service.
Efficient:
SELECT FirstName, LastName, Address, City, State, Zip
FROM Customers
. This query is much cleaner and only pulls the required information for mailing addresses.
• WHERE clauses - In a WHERE clause, the various operators used directly affect how fast a query can run.
Here are the conditional operators used in the WHERE clause, ordered by their precedence:
=, >, <, >=, <=, <>, !=, !>, !<
• Avoid DISTINCT and ORDER BY - If you don't need the DISTINCT/ORDER BY clause, then try to avoid
so. Unnecessary DISTINCT or ORDER BY clauses cause extra work for the database engine. Hence
making performance slower. (Sometimes ORDER BY helps to speed up the operation).
• More WHERE clause hints - Avoid unnecessary conditions in the WHERE Clause. Also try to avoid a
function in the WHERE clause as it presents SQL engine to do index seek. Even it forces SQL full index
scans or even table scans.Also, try to avoid IN. While checking the existence of some values, then use
EXISTS instead of IN. IN counts the NULL values also, but EXISTS not. EXISTS returns Boolean(Yes/No)
but IN returns all values hence result set for IN is heavier than EXISTS.
 Here, teacher and student table has 1:m relationship and I want to find the
teachers who have students. Both the queries have the same result but the
second query will run faster because of EXISTS operator.
SELECT name
FROM teacher
WHERE teacher_id IN (SELECT teacher_id FROM student)
SELECT name
FROM teacher WHERE EXISTS
(SELECT 1 FROM student where teacher.teacher_id=student.teacher_id)

• CREATE TABLE vs. SELECT INTO - Select * INTO works fine for small tables, but when dealing with large
record sets or long-running queries, it creates locks on the system objects within the tempdb database. As a
result, other queries and procedures that need to create objects within the tempdb database will have to wait for
the long-running query to complete. This is because when an object is created, an exclusive lock is taken against
the sysobjects, syscolumns, sysindexes tables.
• SELECT DISTINCT is a handy way to remove duplicates from a query. SELECT DISTINCT
works by Grouping all fields in the query to create distinct results. To accomplish this goal
however, a large amount of processing power is required. Additionally, data may be grouped
to the point of being inaccurate. To avoid using SELECT DISTINCT, select more fields to
create unique results.
Inefficient and inaccurate:
SELECT DISTINCT FirstName, LastName, State
FROM Customers
This query doesn’t account for multiple people in the same state having the same first and last name.
Popular names such as David Smith or Diane Johnson will be grouped together, causing an
inaccurate number of records. In larger databases, a large number of David Smiths and Diane
Johnsons will cause this query to run slowly.
Efficient and accurate:
SELECT FirstName, LastName, Address, City, State, Zip
FROM Customers
By adding more fields, unduplicated records were returned without using SELECT DISTINCT. The
database does not have to group any fields, and the number of records is accurate.
• Fully Qualified Names - Always use the fully qualified name when calling stored procedures.
This would be the format database_name.schema_name.table_name. For example, use EXEC
master.dbo.Your_Proc_name instead of EXEC Your_Proc_name This is a very common mistake,
which causes an extra trip to the procedure cache to get the execution plan for execution. Also try
to use the schema name while creating a procedure. Like: CREATE PROCEDURE
dbo.Your_Proc_name instead of CREATE PROCEDURE Your_Proc_name
• Use proper indexes: Index scans and index seeks are much faster than table scans. So identify the
table scans from the execution plans. But when a table returns smaller number rows, then it is
better to use a table scan.
 CONCLUSIVE POINTS:
1. It is a good practice to use WHERE clause whenever the data is needed in filtered form.
2. First write the query(procedure) in Notepad , then go for the SERVER implementation.
3. Use proper indentation and syntax while writing any type of QUERY.
4. The mistakes that I do most of the times is the ‘HURRY’ for the completion of WORK. Do not
do that or take care of this thing while executing the query.
5. Last but not least if you can wait for the execution of query , execute it in the night hours or
schedule it for that time because at that time Database will have less pressure and more
smoothness.
THANKYOU