Skip to main content

Avoid using functions in WHERE Clause!!

Thumb Rule is as much as possible avoid using FUNCTIONS within WHERE Clause of your SQL Query.

Let me show you some very basic examples to substantiate this theory.

--Table schema
Create table tblDateExample (dtStartDate datetime)
Go

-- Populate dummy records into the table
INSERT tblDateExample VALUES ('2009-04-15 12:00:00.000')
INSERT tblDateExample VALUES ('2009-04-14 12:00:00.000')
INSERT tblDateExample VALUES ('2009-04-13 12:00:00.000')
INSERT tblDateExample VALUES ('2009-04-12 12:00:00.000')
INSERT tblDateExample VALUES ('2009-04-11 12:00:00.000')
INSERT tblDateExample VALUES ('2009-04-11 12:00:00.000')
INSERT tblDateExample VALUES ('2009-04-11 12:00:00.000')
INSERT tblDateExample VALUES ('2009-04-11 12:00:00.000')
INSERT tblDateExample VALUES ('2009-04-10 12:00:00.000')
INSERT tblDateExample VALUES ('2009-04-09 12:00:00.000')
INSERT tblDateExample VALUES ('2009-04-08 12:00:00.000')
INSERT tblDateExample VALUES ('2009-04-07 12:00:00.000')
INSERT tblDateExample VALUES ('2009-04-10 12:00:00.000')
INSERT tblDateExample VALUES ('2009-04-10 12:00:00.000')
INSERT tblDateExample VALUES ('2009-04-10 12:00:00.000')
INSERT tblDateExample VALUES ('2009-04-10 12:00:00.000')

-- Create an Index
Create index IXStartDate on tblDateExample ( dtStartDate )
Go

Using Functions within WHERE Clause

SET SHOWPLAN_TEXT ON
Go

Select dtStartDate from tblDateExample where Convert(Varchar(8), dtStartDate, 112) = '20090411'

SET SHOWPLAN_TEXT OFF
Go

Checkout its execution plan, as expected it doesn’t make use of the Index fully

|—Index Scan (OBJECT:([Testbed].[dbo].[tblDateExample].[IXStartDate]),  WHERE:(CONVERT(varchar(8),[Testbed].[dbo].[tblDateExample].[dtStartDate],112)=[@1]))

Rewrite the same query without a function in the WHERE Clause

SET SHOWPLAN_TEXT ON
Go

Select dtStartDate from tblDateExample where dtStartDate >= '20090411' AND dtStartDate < '20090412'  

SET SHOWPLAN_TEXT OFF
Go

The execution plan shows us that it uses Index Seek.

|—Index Seek (OBJECT:([Testbed].[dbo].[tblDateExample].[IXStartDate]), SEEK:([Testbed].[dbo].[tblDateExample].[dtStartDate] >= CONVERT_IMPLICIT(datetime,[@1],0) AND [Testbed].[dbo].[tblDateExample].[dtStartDate] < CONVERT_IMPLICIT(datetime,[@2],0)) ORDERED FORWARD)

That said, there are instances where we can still make use of Index Seek in spite of using Functions within the WHERE Clause. Check out the below query for an example.

Select dtStartDate from tblDateExample
where
Convert(datetime,dtStartDate,101) > Convert(datetime,'2009-04-11',101) and
Convert(datetime,dtStartDate,101) < Convert(datetime,'2009-04-12',101)

The execution plan for the above query:

|—Index Seek (OBJECT:([Testbed].[dbo].[tblDateExample].[IXStartDate]), SEEK:([Testbed].[dbo].[tblDateExample].[dtStartDate] > CONVERT(datetime,[@1],101) AND [Testbed].[dbo].[tblDateExample].[dtStartDate] < CONVERT(datetime,[@2],101)) ORDERED FORWARD)

On trying to understand the reason for this behavior i noticed there is no real conversion happening in the above query. i.e., Both the Converted type and the original column type are the same :)

Technorati Tags:

Comments

Popular posts from this blog

Script table as - ALTER TO is greyed out - SQL SERVER

One of my office colleague recently asked me why we are not able to generate ALTER Table script from SSMS. If we right click on the table and choose "Script Table As"  ALTER To option would be disabled or Greyed out. Is it a bug? No it isn't a bug. ALTER To is there to be used for generating modified script of Stored Procedure, Functions, Views, Triggers etc., and NOT for Tables. For generating ALTER Table script there is an work around. Right click on the table, choose "Modify" and enter into the design mode. Make what ever changes you want to make and WITHOUT saving it right click anywhere on the top half of the window (above Column properties) and choose "Generate Change Script". Please be advised that SQL Server would drop actually create a new table with modifications, move the data from the old table into it and then drop the old table. Sounds simple but assume you have a very large table for which you want to do this! Then it woul...

AWS fatal error: An error occurred (400) when calling the HeadObject operation: Bad Request

While using AWS and trying to copy a file from a S3 bucket to my EC2 instance ended up with this error message. Command Used: aws s3 cp s3://mybucketname/myfilename.html /var/www/html/ Error: fatal error: An error occurred (400) when calling the HeadObject operation: Bad Request The error goes off if we add the region information to the command statement. I am using Asia Pacific (Mumbai) so used ap-south-1 as the region name. Modified Command: aws s3 cp s3://mybucketname/myfilename.html /var/www/html/ --region ap-south-1

[Non Tech] Want to know the recipe for Omelette :)

Fed up with Bread - Jam and Curd Rice, today i wanted to eat Omelette. Interesting part is I wanted to cook it myself :) So in the first picture you see all the items which are needed for preparing an Omelette. When I had a closer look at the eggs I see that almost all the eggs are broken. But believe me when I bought it couple of days back it was in perfect condition! I was wondering whether the eggs have become rotten or pretty old to consume! I tried taking an egg and break it but couldn't break it at all :) Since I have kept in the freezer all the eggs have frozen and looked like a iron ball :) After trying for few minutes of trying i removed the shell of the egg and then kept that iron ball :) into a bowl and placed it within Oven. I heated it for 1 minute and checked. It melted only to a limit. So i just set it for another 2 minutes and checked it later. It has melted but the part of the egg white has become a Omelette :( I didn't leave it there. I took the bowl out of ...