Please start any new threads on our new site at https://forums.sqlteam.com. We've got lots of great SQL Server experts to answer whatever question you can come up with.

 All Forums
 General SQL Server Forums
 New to SQL Server Programming
 Performance - DATETIME, Indexes, and WHERE Clause

Author  Topic 

RobertKaucher
Posting Yak Master

169 Posts

Posted - 2011-02-14 : 13:52:32
We have all see the questions regarding this. A person new to SQL Server asks how to filter a query and someone less new makes a suggestion like this:


DELETE FROM dbo.DateTimeCRUDTest
WHERE MONTH(InsertDate) = MONTH(GETDATE())-1 AND YEAR(InsertDate) = YEAR(GETDATE())


And then someone who has read Ben-Gan or has more experience states that you should not perform opperations on columns in a WHERE clause because it degrades performance by not allowing SQL Server to use the index properly. On my own PC I populated a database with more than 94000 rows. Dates ranged from the current datetime back to the early 1700. I used PowerShell to populate the tables.


#You need SQLPSX to run this.
$MyNumber = 100000

for($i=0; $i -lt $MyNumber; $i++)
{
$MyDate = ([datetime]::now).AddDays(-$i) -f "YYYYMMDD"
Set-SqlData -dbname TestDb -sqlserver "(local)" -qry "INSERT INTO DateTimeCRUDTest(Description,InsertDate) VALUES('Some text to add a little realism - $MyDate', '$MyDate')"
}


I then ran these queries without an index:

USE TestDb
GO

DELETE FROM dbo.DateTimeCRUDTest
WHERE InsertDate BETWEEN DATEADD(MONTH,datediff(month,0,getdate())-1,0) AND DATEADD(day,-1,DATEadd(MONTH,datediff(month,0,GETDATE()),0))
--RESTORE DB
USE TestDb
GO

DELETE FROM dbo.DateTimeCRUDTest
WHERE MONTH(InsertDate) = MONTH(GETDATE())-1 AND YEAR(InsertDate) = YEAR(GETDATE())


.0431 seconds and .0415 seconds respectively. Not a huge change. I added an index to the datetime column and got .037 and .026 respectively. Not a big variation, but the "wrong query" was running faster.

I then ran these two:

USE TestDb
GO

DELETE FROM dbo.DateTimeCRUDTest
WHERE InsertDate BETWEEN DATEADD(MONTH,datediff(month,0,DATEADD(YEAR,-100,getdate()))-1,0) AND DATEADD(day,-1,DATEadd(MONTH,datediff(month,0,DATEADD(YEAR,-100,getdate())),0))


USE TestDb
GO

DELETE FROM dbo.DateTimeCRUDTest
WHERE MONTH(InsertDate) = MONTH(GETDATE())-1 AND YEAR(InsertDate) = YEAR(GETDATE())-100

.020 seconds for the qury that did not opperate on the column in the WHERE clause and .30 seconds for the one that did.

Why would this be? And are these variations really a big deal in the average environment?



===
http://www.ElementalSQL.com/

tkizer
Almighty SQL Goddess

38200 Posts

Posted - 2011-02-14 : 13:55:16
I think your test table isn't big enough. Try with a table that has million of rows in it.

Tara Kizer
Microsoft MVP for Windows Server System - SQL Server
http://weblogs.sqlteam.com/tarad/

Subscribe to my blog
Go to Top of Page

RobertKaucher
Posting Yak Master

169 Posts

Posted - 2011-02-14 : 14:14:57
I'm adding 10 million rows. Do you believe the row "width" will have any bearing? Should I add more fields/data?

===
http://www.ElementalSQL.com/
Go to Top of Page

tkizer
Almighty SQL Goddess

38200 Posts

Posted - 2011-02-14 : 14:20:55
The row width only matters for the clustered index, which will likely matter in the case of a scan for your function test. Depends on the execution plan though.

Tara Kizer
Microsoft MVP for Windows Server System - SQL Server
http://weblogs.sqlteam.com/tarad/

Subscribe to my blog
Go to Top of Page

RobertKaucher
Posting Yak Master

169 Posts

Posted - 2011-02-15 : 11:42:38
My laptop hibernated so I only got just under 3 million rows. Same queries as above.

With an index on date field
Using between: 0.145 seconds
Operating on column in WHERE: 0.793 seconds

With no index on datefield
Using between: 8.452 seconds
Operating on column in WHERE: 8.377 seconds

So in the case of the indexed version of the table, the number of rows really did matter as you thought it would. I still find it interesting that without an index the wrong way is slightly faster. Of course that does not matter in the real world, though, of course you will (or should) have an index in most cases. Thanks, Tara!


===
http://www.ElementalSQL.com/
Go to Top of Page

namman
Constraint Violating Yak Guru

285 Posts

Posted - 2011-02-15 : 21:57:33


.0431 seconds and .0415 seconds respectively. Not a huge change. I added an index to the datetime column and got .037 and .026 respectively. Not a big variation, but the "wrong query" was running faster.


Because both are "wrong" queries
Go to Top of Page

RobertKaucher
Posting Yak Master

169 Posts

Posted - 2011-02-16 : 09:28:50
quote:
Originally posted by namman



.0431 seconds and .0415 seconds respectively. Not a huge change. I added an index to the datetime column and got .037 and .026 respectively. Not a big variation, but the "wrong query" was running faster.


Because both are "wrong" queries



Could you explain what you mean?

===
http://www.ElementalSQL.com/
Go to Top of Page
   

- Advertisement -