原文：Demystifying the SQL Server DATETIME Datatype
来源：SQL-Server-Performance.com
作者：Frank Kalis
你和发现网上很多SQL Server的问题是关于DATETIME数据类型的，这似乎说明熟练使用DATETIME并不容易。
奇 怪的是，我却一直相信使用DATETIME是不难的事。DATETIME并非复杂的数据类型，也没有深奥的日期算法。唯一需要理解的是为了安全的处理临时 数据，DATETIME数据类型的一些基本概念。本文的目的就是帮助读者理解这些SQL Server有趣的地方，以及弄清楚DATETIME数据类型的一些真相。
本文我都会使用ISO日期格式 yyyymmdd。这是一种安全的日期格式，即无论你的电脑如何设置，该格式都可以运行正常，而且它也不受SET DATEFORMAT或者SET LANGUAGE设置的影响。即使你不开发国际用户的数据库应用，也最好养成使用安全的日期格式的习惯。SQL Server只有两种日期类型格式编号是安全的，112和116。112是ISO格式，116是ISO8601格式。在SQL Server联机帮助的CAST和CONVERT主题中可以找到关于这两种日期编号的介绍。你越早养成这些习惯，很多潜在的 问题就越少。
你将注意到，我特意使用了隐示地将CHAR转换成DATETIME。隐示转换有时候不是一种良好的开发习惯，不过根据 SQL Server数据类型中，DATETIME转换的优先级高，我认为转换是安全的。关于这点本文就不多阐述了。
本 文先来研究一下DATETIME数据类型的内部表现形式，然后将注意力转移到DATETIME相关的查询上，最后总结一些注意事项，小技巧和常见问题的解 决方法。 所有的代码示例都适用于SQL Server 2000，我相信对于以前的SQL Server版本也应该适用。对于2000以后的版本，我将 检查本文并对不适用的地方作相应的改动。
好了，让我们开始吧！
DATETIME类型的数据的可读性
Select CAST(GETDATE() AS BINARY(8)) AS WhatIsReallyStored
WhatIsReallyStored
——————
0×00009620016CE3A8
(1 row(s) affected)
我必须承认，我对16进制数并不那么精通，所以我想我无法直接告诉你这串数字表示的是 2005-03-23 22:08:31.280. 
SQL Server联机帮助(SQL Server Books Online :BOL)的解释是 “DATETIME数据类型的值储存在2个4byte长度的整数中。”
说明就只有这些。
注 意，BOL并没有说DATETIEM类型的值是保存在某种特定的日期或者时间格式中，而这些格式是依赖于 语言和计算机设置的! 而仅仅是说储存在2个整型数值中。这并非100％的描述清楚了。其实是这样的，该值的确是储存在2个4byte长度的整型中，但是被打包成了 BINARY(8)。前4个字节保存和19000101这个日期的 差值，我们知道SQL Server的基准日期是19000101。
后4个字节保存时间数据，该数据是以午夜开始的累积毫秒数。
这些也能在BOL中找到相关的介绍。下面我们用一个简单的脚本来检验。
DECLARE @300 BINARY(8)
SET @300 = 0×00000000 + CAST(300 AS BINARY(4))
在 讨论运行结果前，我们先来看一下该脚本干什么用。首先定义了一个SQL Server DATETIME内部数据类型。然后我们将前4个byte(即日期部分)赋值为0×00000000。这意味着我们将它设置为基准日期 (=19000101)。然后在日期部分后连接一个时间部分。时间部分赋值为300，根据BOL，我们知道，这表示300毫秒，即 1/3秒。运行脚本
Select
@300
, CAST(@300 AS DATETIME)
—————— ——————————————————
0×000000000000012C 1900-01-01 00:00:01.000
(1 row(s) affected)
奇怪，我们的结果显示是1秒，而不是300毫秒。反过来推理，赋值300表示1秒，也就是说它并不是 表示300毫秒，而是300/300秒，即1秒。
实际上，SQL Server的确储存从午夜开始的时钟。每个时钟单位是3.33毫秒。这也就是为什么DATETIME 数据类型最小精确度是1/300。在BOL关于也是如此介绍的。
DATETIME数据类型的基本查询
本节我们将利用SQL Server自带的Northwind示例数据库。
DATETIME查询和其它数值查询方式是一样的。也就是说，你可以使用数值类型可以使用的比较操作，如 =, <>, >= or <=。而且也可以使用逻辑操作，如 LIKE 或 BETWEEN。下面进行示例。
Example 1: 检索条件为特定时间：
Select
CustomerID
, orderDate
FROM
orders
Where
orderDate = ‘19960704′
CustomerID orderDate
———- ——————————————————
VINET 1996-07-04 00:00:00.000
(1 row(s) affected)
注意，这里有一个使用DATETIME最重要的地方。既然DATETIME类型既包括日期部分，也包括时间部分， 查询中就要考虑这两个部分。幸运的是，Northwind orders数据表只保存日期信息在OrderDate列中。为了 说明问题，我们修改查询如下：
Update
orders
SET
orderDate = ‘19960704 12:31:00′
Where
CustomerID=’VINET’
AND
orderDate = ‘19960704′
GO
CustomerID orderDate
———- ——————————————————
(0 row(s) affected)
避免该情况唯一可做的就是在Where语法后同时指定时期和时间。然而在大多数情况下，我们并 不知道确切的时间或者只是对日期感兴趣。
Example 2: 检索条件为阶段性时间
上面的例子中我们想把所有日期为’19960704′的记录查找出来，但是没有成功。下面我们给出有效的办法。
Select
CustomerID
, orderDate
FROM
orders
Where
orderDate >= ‘19960704′
AND
orderDate < ‘19960705′
CustomerID orderDate
———- ——————————————————
VINET 1996-07-04 12:31:00.000
(1 row(s) affected)
上面是满足需求的最简单办法。基本思路就是你指定大于’19960704′(从凌晨00:00:00开始)，小于 ‘19960705′(到午夜00:00:00结束)的时间段，搜索该时间段内的记录。这样处理，你就不必去做分割时间格式等工作，上面的查询还可以改写 为：
Select
CustomerID
, orderDate
FROM
orders
Where
orderDate
BETWEEN
‘19960704′
AND
‘19960705′
CustomerID orderDate
———- ——————————————————
VINET 1996-07-04 12:31:00.000
TOMSP 1996-07-05 00:00:00.000
(2 row(s) affected)
需要注意的是，上面的写法也许会造成一点麻烦，因为BETWEEN会搜索包括结束日期在内的记录。 BETWEEN的确是这样搜索的，比如我们改写为：
Select
CustomerID
, orderDate
FROM
orders
Where
orderDate
BETWEEN
‘19960704′
AND
‘19960704′
CustomerID orderDate
———- ——————————————————
(0 row(s) affected)
这样，查询就无效了。如果不显式设置，SQL Server缺省将时间设置为午夜(00:00:00)。 因此，上面的查询无法找出时间不为午夜的任何记录。前面三个例子中，第一个例子是安全的， 推荐使用。无论采取那种方式，首要的是要搞清楚我们想要的到底是什么。
顺便提一下，上面查询在执行计划中，SQL Server会自动将BETWEEN解析为 >= 和 <= 的方式。因此，无法查询出记录也就不奇怪了。在执行计划中，解析的信息如下：
…SEEK:([Orders].[OrderDate] >= Convert([@1]) AND [Orders].[OrderDate] <= Convert([@2]))…
上面例子中，我们实际用到了 >= 和 <= ，所以也不用专门给出这两个操作的例子了。 我们来看一下LIKE操作符的用法。BOL中指出LIKE可以用于搜索日期和时间部分，基本用法如下：
Select
CustomerID
, orderDate
FROM
orders
Where
orderDate
LIKE
‘%1996%’
CustomerID orderDate
———- ——————————————————
VINET 1996-07-04 12:31:00.000
TOMSP 1996-07-05 00:00:00.000
HANAR 1996-07-08 00:00:00.000
…
在 这个例子中，我们要查找1996年的记录。现在我们扩展一下需求，查找1996年7月份的所有记录。也许有人会用 LIKE ‘%1996-07%’的Where条件。然而运行这种查询后，检索不到任何记录。为了叙述简单，我只是建议大家不要局限于DATETIME的LIKE操 作用法。当处理日期或者时间的一部分时，SQL Server提供了一个更方便的内置函数，上面 的例子可改写为：
Select
CustomerID
, orderDate
FROM
orders
Where
DATEPART(yyyy,OrderDate)=1996
CustomerID orderDate
———- ——————————————————
VINET 1996-07-04 12:31:00.000
TOMSP 1996-07-05 00:00:00.000
HANAR 1996-07-08 00:00:00.000
…
利用DATEPART函数，可以很容易对月份进行查询。
Select
CustomerID
, orderDate
FROM
orders
Where
DATEPART(yyyy,OrderDate)=1996
AND
DATEPART(mm,OrderDate)=7
CustomerID orderDate
———- ——————————————————
VINET 1996-07-04 12:31:00.000
TOMSP 1996-07-05 00:00:00.000
HANAR 1996-07-08 00:00:00.000
…
我还是建议使用Example 2的方式，如：
Select
CustomerID
, orderDate
FROM
orders
Where
orderDate >= ‘19960701′
AND
orderDate < ‘19960801′
DATETIME高级查询
本 节中要讨论的是，当对DATETIME查询时，我们是否应该多选择DATEADD()或者DATEDIFF()函数。实际 上，DATEADD()，DATEDIFF()和>=,<=并没有多大的区别。假设OrderDate字段有聚集索引，那么这两种方式得到的 性能结果基本是一样的。不过，我还是建议多使用DATEADD函数。原因下面阐述。
假设你想要知道从某天开始起，经过7天后的那个日期的订单情况，查询大致如下：
DECLARE @dt DATETIME
SET @dt = ‘19960701′
Select
orderID
, CustomerID
FROM
orders
Where
orderDate = DATEADD(DAY,7,@dt)
orderID CustomerID
———– ———-
10250 HANAR
10251 VICTE
(2 row(s) affected)
既然OrderDate字段上有索引，那么执行计划显示为：
…|–Index Seek(OBJECT:([Northwind].[dbo].[Orders].[OrderDate])…
SQL Server当然会用到该字段的索引，然后再看看I/O情况
Table ‘Orders’. Scan count 1, logical reads 6, physical reads 0, read-ahead reads 0.
然后我们看看DATEDIFF函数的效果：
Select
orderID
, CustomerID
FROM
orders
Where
DATEDIFF(d,@dt,OrderDate)=7
orderID CustomerID
———– ———-
10250 HANAR
10251 VICTE
(2 row(s) affected)
当然查询结果是一样的，那么执行计划如何呢？
…|–Clustered Index Scan(OBJECT:([Northwind].[dbo].[Orders].[PK_Orders])…
显然，SQL Server无法使用OrderDate字段的索引，因此只有扫描整个表才能给出查询结果。从I/O性能 上我们能得出相同的推断：
Table ‘Orders’. Scan count 1, logical reads 21, physical reads 0, read-ahead reads 0.
使用DATEDIFF的逻辑读取次数是使用DATEADD的3倍多!
当然，Orders表只有830条记录，因此无论那种方式运行都很快。但是如果记录很多时，情况就不一样了， 至少我肯定愿意使用DATEADD函数。
如何在当前日期加上(减去)N天?
正确的回答是使用DATEADD函数，例如：
DECLARE @dt DATETIME
SET @dt = ‘20050325′
Select
DATEADD(d,1,@dt)
——————————————————
2005-03-26 00:00:00.000
(1 row(s) affected)
其实，既然SQL Server’s的基础日期单位是天，因此也可以：
Select
@dt+1
——————————————————
2005-03-26 00:00:00.000
(1 row(s) affected)
两种方式是等价的，都对某日期加上N天。如果是减去N天，把N改成-N天就行了。
这种处理同样适用于天数的分割。假设你要对上面的日期加上2个小时，可以如下使用：
DECLARE @dt DATETIME
SET @dt = ‘20050325′
Select
DATEADD(hh,2,@dt)
——————————————————
2005-03-25 02:00:00.000
(1 row(s) affected)
或者写为：
Select
@dt+0.08333333333333333
——————————————————
2005-03-25 02:00:00.000
(1 row(s) affect
从上面的分析中，我们可以知道为什么选择用DATEADD函数。因为它比较容易被理解，而 也不必将2个小时具体换算成天为单位，例如 2小时＝2/24天＝0.08333333333333333天。
为什么可以用 DATEADD(d, DATEDIFF(d, 0…))的方法来去掉时间部分对结果的影响?
准确的说，SQL Server 2000以及以前的版本，DATETIME数据类型总是包含两部分：日期和时间。你不能 把这两部分分割开。所以用“去掉”这个词可能会造成误解。其实我们是把时间部分设置为午夜时间，从而 来避免错误的发生。下面是其中的一种用法：
Select
DATEADD(d,DATEDIFF(d,0,GETDATE()),0)
——————————————————
2005-03-23 00:00:00.000
(1 row(s) affected)
我们来解剖该语句，看看它为什么能去掉时间影响。首先
Select
DATEDIFF(d,0,GETDATE())
———–
38432
(1 row(s) affected)
这句查询是关键!
DATEDIFF函数返回两个日期间的天数差，如：
Select
DATEDIFF(d,’20050228 23:59:59.997′, ‘20050301 00:00:00.000′)
———–
1
(1 row(s) affected)
当然没有人会认为上面那两个时间差是1天。但是，既然DATEPART参数是d，DATEDIFF函数就只会考虑 日期部分，下面的语句和上面的查询实际上效果是一样的。
Select
DATEDIFF(d,’20050228′, ‘20050301′)
———–
1
(1 row(s) affected)
因 此无论实际上两个时间有多接近，你最后得到的结果总是1天。回到上面的例子，DATEDIFF返回基准日期和当前日期之间的天数。太棒了，这样我们就可以 得到想要的结果，而不必去处理时间部分。我们只需要将DATEDIFF得到的结果放入DATEADD函数中去计算即可。
Select
DATEADD(d,DATEDIFF(d,0,GETDATE()),0)
, DATEADD(d,38432,0)
—————————————————— ——————————————————
2005-03-23 00:00:00.000 2005-03-23 00:00:00.000
(1 row(s) affected)
当写本文时，我觉得这真是简单。
Select
CAST(DATEDIFF(d,0,GETDATE()) AS DATETIME)
——————————————————
2005-03-23 00:00:00.000
(1 row(s) affected)
上面的例子也能很好的达到目的。
正如你所看到的，这不涉及任何复杂的日期或者数值算法。坦率地说，这其实很简单。而且，对于DATEDIFF 和DATEADD函数的任何参数来说，道理是一样的。
最后提一下，我们还可以利用DATETIME的内部存储格式来设置一个DATETIME类型的时间部分为午夜时间，如：
Select
CAST(SUBSTRING(CAST(GETDATE() AS BINARY(8)),1,4) + 0×00000000 AS
DATETIME)
, CAST(CAST(SUBSTRING(CAST(GETDATE() AS BINARY(8)),1,4) AS INT) AS
DATETIME)
—————————————————— ——————————————————
2005-03-23 00:00:00.000 2005-03-23 00:00:00.000
(1 row(s) affected)