|
一、場景
在SQL Server 2005中,有一個表TestDatetime,其中Dates這個字段的數(shù)據(jù)類型是datetime,如果你看到表的記錄如下圖所示,你最先想到的是什么呢?
(圖1:數(shù)據(jù)列表)
你看到這些數(shù)據(jù),是不是覺得這樣的設(shè)計既浪費了存儲空間,又使得這個列的索引增大,查詢起來更慢,你也想使用一些其它的數(shù)據(jù)類型來代替這個datetime吧?
其實大家都是這么想的,這個方向是100%正確的,但是在寫這篇文章以前,我進入了兩個誤區(qū):(如果你中了下面的兩個誤區(qū),那么請你看看這篇文章吧。)
誤區(qū)一: 把Dates字段的datetime數(shù)據(jù)類型換成smalldatetime,這樣數(shù)據(jù)就由:‘2009-04-0900:00:00.000’變?yōu)?lsquo;2009-04-09 00:00:00’,這個看起來沒有減少多少存儲空間哦。
誤區(qū)二:把Dates字段的datetime數(shù)據(jù)類型換成char(10),這樣數(shù)據(jù)就由:‘2009-04-09 00:00:00.000’變?yōu)?lsquo;2009-04-09’,這好像能減少很多存儲空間哦。
二、分析
在SQL Server 2005版本中保存日期的數(shù)據(jù)類型只有兩種:datetime、smalldatetime,但是在SQL Server 2008版本中新增了一些日期數(shù)據(jù)類型:time、date、smalldatetime、datetime、datetime2、datetimeoffset,其中的date類型就能滿足我們場景中的需求了,如果你幸運的在使用SQL Server 2008的話,那么恭喜你,請使用date數(shù)據(jù)類型吧。
但是我就比較可悲一點了,在使用SQL Server 2005的前提下,我進入了誤區(qū)一、誤區(qū)二。其實這也是因為自己忽略了一下基礎(chǔ)性的東西,如果知道不同數(shù)據(jù)類型的存儲空間大小,也許就很輕易的避免這樣低級的錯誤了。
其實你查看表TestDatetime中的Dates字段的時候,看到查詢結(jié)果中的:“-”、“:”只是用于顯示的,并不是真實保存的時候就這樣格式的。
datetime占用8個字節(jié),前4個字節(jié)存儲basedate(即1900年1月1日)之前或之后的天數(shù),后4個字節(jié)存儲午夜后的毫秒數(shù)。值范圍:1753-01-01 到 9999-12-31。
smalldatetime占用4個字節(jié),前2個字節(jié)存儲base date(1900年1月1日)之后的天數(shù)。后2個字節(jié)存儲午夜后的分鐘數(shù)。值范圍:1900-01-01 到 2079-06-06。
date占用3個字節(jié),它比smalldatetime的前2個字節(jié)多了1字節(jié),所以值的范圍更廣了。值范圍:0001-01-01 到 9999-12-31。
所以,如果你使用char(10)來保存截斷的日期,那么你的存儲空間反而更大了。
結(jié)論: 如果是SQL Server 2005,那么請你使用smalldatetime吧,數(shù)據(jù)能節(jié)約一半,雖然查詢的時候看起來沒什么改變;如果你是SQLServer 2008,那么請你使用date吧,
雖然3個字節(jié)跟4個字節(jié)沒有多大的差距,但是從設(shè)計上和邏輯清晰度上都有很大的提升,而且差距有些時候并不是1個字節(jié)的問題,比如當(dāng)表數(shù)據(jù)量達到幾個億的時候,還是有差別的,又或者一條記錄可能因為差1個字節(jié)就剛剛好給8060字節(jié)的頁瓜分,這些都不容忽視的。
三、測試
下面我們就從數(shù)據(jù)存儲的大小、索引存儲的大小、索引使用時候的速度這幾個方面進行測試:(這里只測試數(shù)據(jù)類型:,,數(shù)據(jù)的內(nèi)容都是一樣的)
(一) 測試前奏:
1. 創(chuàng)建三種數(shù)據(jù)類型char(10)、datetime、smalldatetime的表;(表結(jié)構(gòu)如下面SQL)
CREATE TABLE[dbo].[TestDatetime](
[Id] [int] IDENTITY(1,1) NOT NULL,
[Dates] [datetime] NULL,
CONSTRAINT[PK_TestDatetime] PRIMARY KEY CLUSTERED
(
[Id] ASC
)WITH (IGNORE_DUP_KEY = OFF) ON [PRIMARY]
) ON[PRIMARY]
2. 插入相同記錄到三個表中;(這里插入1210000條記錄)
3. 為[Dates]字段創(chuàng)建索引;(在創(chuàng)建索引的時候可以設(shè)置填充因子為100%)
4. 查看索引屬性中的索引碎片信息,查看表數(shù)據(jù)和索引占用的空間,測試[Dates]字段索引的查詢效率;
(二) 測試結(jié)果:
1. 數(shù)據(jù)存儲大小:
(圖2:數(shù)據(jù)空間對比)
2. 索引存儲信息:
(圖3:char(10))
(圖4:datetime)
(圖5:smalldatetime)
3. 索引查詢的情況:
多次執(zhí)行,SQL Server執(zhí)行時間為:[char(10)] 大部分在43~59徘徊,偶爾出現(xiàn)小于10的;[datetime]平均在1~2毫秒;[smalldatetime]均在1毫秒;而且大家會發(fā)現(xiàn)[smalldatetime]有其它的9次邏輯讀取變?yōu)?span lang="EN-US">8次了。
--[TestChar10]
SQL Server 分析和編譯時間:
CPU 時間=0 毫秒,占用時間=1 毫秒。
(2200 行受影響)
表'TestChar10'。掃描計數(shù)1,邏輯讀取9次,物理讀取0次,預(yù)讀0次,lob邏輯讀取0次,lob物理讀取0次,lob預(yù)讀0次。
SQL Server 執(zhí)行時間:
CPU 時間=0 毫秒,占用時間=59 毫秒。
SQL Server 執(zhí)行時間:
CPU 時間=0 毫秒,占用時間=1 毫秒。
--[TestDatetime]
SQL Server 分析和編譯時間:
CPU 時間=0 毫秒,占用時間=1 毫秒。
(2200 行受影響)
表'TestDatetime'。掃描計數(shù)1,邏輯讀取9次,物理讀取0次,預(yù)讀0次,lob邏輯讀取0次,lob物理讀取0次,lob預(yù)讀0次。
SQL Server 執(zhí)行時間:
CPU 時間=0 毫秒,占用時間=2 毫秒。
SQL Server 執(zhí)行時間:
CPU 時間=0 毫秒,占用時間=1 毫秒。
--[TestSmalldatetime]
SQL Server 分析和編譯時間:
CPU 時間=0 毫秒,占用時間=1 毫秒。
(2200 行受影響)
表'TestSmalldatetime'。掃描計數(shù)1,邏輯讀取8次,物理讀取0次,預(yù)讀0次,lob邏輯讀取0次,lob物理讀取0次,lob預(yù)讀0次。
SQL Server 執(zhí)行時間:
CPU 時間=0 毫秒,占用時間=1 毫秒。
SQL Server 執(zhí)行時間:
CPU 時間=0 毫秒,占用時間=1 毫秒。
--SQL Server 2008新數(shù)據(jù)類型
SELECT
CAST('2007-05-08 12:35:29. 1234567+12:15' AS time(7)) AS 'time'
,CAST('2007-05-08 12:35:29. 1234567 +12:15' AS date) AS 'date'
,CAST('2007-05-08 12:35:29.123' AS smalldatetime) AS
'smalldatetime'
,CAST('2007-05-08 12:35:29.123' AS datetime) AS 'datetime'
,CAST('2007-05-08 12:35:29. 1234567 +12:15' AS datetime2(7)) AS 'datetime2'
,CAST('2007-05-08 12:35:29.1234567 +12:15' AS datetimeoffset(7)) AS 'datetimeoffset';
四、參考文獻
日期和時間數(shù)據(jù)類型及函數(shù)(Transact-SQL)
it知識庫:SQL Server datetime數(shù)據(jù)類型設(shè)計、優(yōu)化誤區(qū),轉(zhuǎn)載需保留來源!
鄭重聲明:本文版權(quán)歸原作者所有,轉(zhuǎn)載文章僅為傳播更多信息之目的,如作者信息標(biāo)記有誤,請第一時間聯(lián)系我們修改或刪除,多謝。