当前位置:七道奇文章资讯数据防范MSSQL防范
日期:2011-05-02 14:53:00  来源:本站整理

SQL Server datetime数据范例计划、优化误区[MSSQL防范]

赞助商链接



  本文“SQL Server datetime数据范例计划、优化误区[MSSQL防范]”是由七道奇为您精心收集,来源于网络转载,文章版权归文章作者所有,本站不对其观点以及内容做任何评价,请读者自行判断,以下是其具体内容:

场景在sql server 2005中,有一个表TestDatetime,此中Dates这个字段的数据范例是datetime,假如你看到表的记录以下图所示,你最早想到的是什么呢?

SQL Server datetime数据范例计划、优化误区
(图1:数据列表)

你看到这些数据,是不是认为这样的计划既浪费了存储空间,又使得这个列的索引增大,查询起来更慢,你也想利用一些别的的数据范例来替换这个datetime吧?

其实大家都是这么想的,这个方向是100%精确的,但是在写这篇文章从前,我进入了两个误区:(假如你中了下面的两个误区,那么请你看看这篇文章吧.)

误区一: 把Dates字段的datetime数据范例换成smalldatetime,这样数据就由:'2009-04-09 00:00:00.000'变成'22009-04-09 00:00:00',这个看起来没有削减多少存储空间哦.

误区二:把Dates字段的datetime数据范例换成char(10),这样数据就由:'2009-04-09 00:00:00.000'变成'2009-04-09',这仿佛能削减很多存储空间哦.

2、解析

SQL Server 2005版本中保存日期的数据范例只有两种:datetime、smalldatetime,但是在SQL Server 2008版本中新增了一些日期数据范例:time、date、smalldatetime、datetime、datetime2、datetimeoffset,此中的date范例就可以满意我们场景中的需求了,假如你幸运的在利用SQL Server 2008的话,那么恭喜你,请利用date数据范例吧.

但是我就对比可悲一点了,在利用SQL Server 2005的前提下,我进入了误区1、误区二.其实这也是因为自己忽视了一下底子性的东西,假如知道差别数据范例的存储空间大小,大概就很简单的避免这样初级的错误了.

其实你查看表TestDatetime中的Dates字段的时刻,看到查询后果中的:"-"、":"只是用于显示的,并非真实保存的时刻就这样格局的.

datetime占用8个字节,前4个字节存储base date(即1900年1月1日)之前或之后的天数,后4个字节存储午夜后的毫秒数.值范围:1753-01-01 到 9999-12-31.

smalldatetime占用4个字节,前2个字节存储base date(1900年1月1日)之后的天数.后2个字节存储午夜后的分钟数.值范围:1900-01-01 到 2079-06-06.

date占用3个字节,它比smalldatetime的前2个字节多了1字节,所以值的范围更广了.值范围:0001-01-01 到 9999-12-31.

所以,假如你利用char(10)来保存截断的日期,那么你的存储空间反而更大了.

结论: 假如是SQL Server 2005,那么请你利用smalldatetime吧,数据能节俭一半,固然查询的时刻看起来没什么改变;假如你是SQL Server 2008,那么请你利用date吧,

固然3个字节跟4个字节没有多大的差别,但是从计划上和逻辑清楚度上都有很大的晋升,并且差别有些时刻并非1个字节的问题,比方当表数据量到达几个亿的时刻,还是有差别的,又大概一条记录大概因为差1个字节就方才好给8060字节的页瓜分,这些都不容轻忽的.

3、测试

下面我们就从数据存储的大小、索引存储的大小、索引利用时刻的速度这几个方面举行测试:(这里只测试数据范例:,,数据的内容都是一样的)

(一) 测试前奏:

1. 成立三种数据范例char(10)、datetime、smalldatetime的表;(表构造以下面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]字段成立索引;(在成立索引的时刻可以设置填充因子为100%)

4. 查看索引属性中的索引碎片信息,查看表数据和索引占用的空间,测试[Dates]字段索引的查询效率;

(二) 测试后果:

1. 数据存储大小:

SQL Server datetime数据范例计划、优化误区

(图2:数据空间比较)

2. 索引存储信息:

SQL Server datetime数据范例计划、优化误区
(图3:char(10))

SQL Server datetime数据范例计划、优化误区
(图4:datetime)

SQL Server datetime数据范例计划、优化误区
(图5:smalldatetime)

3. 索引查询的情形:

多次履行,SQL Server履行时间为:[char(10)] 大部份在43~59徘徊,无意呈现小于10的;[datetime]平均在1~2毫秒;[smalldatetime]均在1毫秒;并且大家会发现[smalldatetime]有别的的9次逻辑读取变成8次了.

--[TestChar10]

SQL Server 解析和编译时间:

CPU 时间= 0 毫秒,占用时间= 1 毫秒.

(2200 行受影响)

表'TestChar10'.扫描计数1,逻辑读取9 次,物理读取0 次,预读0 次,lob 逻辑读取0 次,lob 物理读取0 次,lob 预读0 次.

SQL Server 履行时间:

CPU 时间= 0 毫秒,占用时间= 59 毫秒.

SQL Server 履行时间:

CPU 时间= 0 毫秒,占用时间= 1 毫秒.

--[TestDatetime]

SQL Server 解析和编译时间:

CPU 时间= 0 毫秒,占用时间= 1 毫秒.

(2200 行受影响)

表'TestDatetime'.扫描计数1,逻辑读取9 次,物理读取0 次,预读0 次,lob 逻辑读取0 次,lob 物理读取0 次,lob 预读0 次.

SQL Server 履行时间:

CPU 时间= 0 毫秒,占用时间= 2 毫秒.

SQL Server 履行时间:

CPU 时间= 0 毫秒,占用时间= 1 毫秒.

--[TestSmalldatetime]

SQL Server 解析和编译时间:

CPU 时间= 0 毫秒,占用时间= 1 毫秒.

(2200 行受影响)

表'TestSmalldatetime'.扫描计数1,逻辑读取8 次,物理读取0 次,预读0 次,lob 逻辑读取0 次,lob 物理读取0 次,lob 预读0 次.

SQL Server 履行时间:

CPU 时间= 0 毫秒,占用时间= 1 毫秒.

SQL Server 履行时间:

CPU 时间= 0 毫秒,占用时间= 1 毫秒.

--SQL Server 2008新数据范例

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';   以上是“SQL Server datetime数据范例计划、优化误区[MSSQL防范]”的内容,如果你对以上该文章内容感兴趣,你可以看看七道奇为您推荐以下文章:

  • Windows 搭配 IIS7 PHP MySQL 环境
  • sqlserver索引的原理及索引成立的注意事项小结
  • SQL Join的一些总结(实例)
  • SQL的Join利用图解教程
  • SQL中JOIN和UNION辨别、用法及示例介绍
  • 关于SQL中CTE(公用表表达式)(Common Table Expression)的总结
  • mysql Out of memory (Needed 16777224 bytes)的错误办理
  • mysql提醒[Warning] Invalid (old?) table or database name问题的办理办法
  • mysql启用skip-name-resolve情势时呈现Warning的处理办法
  • mysql启用skip-name-resolve情势时呈现Warning的处理办法
  • MySQL Order By语法介绍
  • <b>MySQL ORDER BY 的实现解析</b>
  • 本文地址: 与您的QQ/BBS好友分享!
    • 好的评价 如果您觉得此文章好,就请您
        0%(0)
    • 差的评价 如果您觉得此文章差,就请您
        0%(0)

    文章评论评论内容只代表网友观点,与本站立场无关!

       评论摘要(共 0 条,得分 0 分,平均 0 分) 查看完整评论
    Copyright © 2020-2022 www.xiamiku.com. All Rights Reserved .