sql server 中 bigint 和 datetime 性能比较

-- 创建表
create table Test_tbl
(
    ID varchar(40) primary key nonclustered,
    IntCol int,
	DateCol datetime
) 

--==================================================================================
-- 【100w数据测试】
--==================================================================================
-- 创建100w测试数据
declare @j int
declare @data float
declare @style bigint
set @j = 1
while @j<1000000
    begin
       set @style = cast(replace(replace(replace(convert(varchar(30),GETDATE(),120),‘-‘,‘‘),‘:‘,‘‘), ‘ ‘, ‘‘) as bigint)
       insert into Test_tbl(ID, IntCol, DateCol) values(NEWID(),@style, getdate())
    set @j = @j + 1
end 

declare @d datetime
set @d = getdate()
declare   @i   int

print ‘【100w数据 查询100次测试】‘
-- 测试性能1,datetime
-------------------------------------------------------------------------------------
set nocount on -- 不显示受影响行数
set   @i=0
while   @i <20
begin
    select top 1 * from Test_tbl where DateCol>getdate()
    set   @i   =   @i+1
end
-------------------------------------------------------------------------------------
select [语句执行时间(毫秒)]=datediff(ms, @d, getdate())
set nocount off
print ‘100w数据 date 语句执行时间(毫秒):‘ + CONVERT(varchar(30), datediff(ms, @d, getdate()))

-- 测试性能2,int
-------------------------------------------------------------------------------------
set nocount on -- 不显示受影响行数
set   @i=0
while   @i <20
begin
    select top 1 * from Test_tbl where IntCol>20151212030303
    set   @i   =   @i+1
end
-------------------------------------------------------------------------------------
select [语句执行时间(毫秒)]=datediff(ms, @d, getdate())
set nocount off
print ‘100w数据 int 语句执行时间(毫秒):‘ + CONVERT(varchar(30), datediff(ms, @d, getdate()))

--==================================================================================
-- 【1000w数据测试】
--==================================================================================
-- 创建900w测试数据,累计1000w
set @j = 1
while @j<9000000
    begin
       set @style = cast(replace(replace(replace(convert(varchar(30),GETDATE(),120),‘-‘,‘‘),‘:‘,‘‘), ‘ ‘, ‘‘) as bigint)
       insert into Test_tbl(ID, IntCol, DateCol) values(NEWID(),@style,getdate())
    set @j = @j + 1
end 

print ‘【1000w数据 查询100次测试】‘
-- 测试性能1,datetime
-------------------------------------------------------------------------------------
set nocount on -- 不显示受影响行数
set   @i=0
while   @i <100
begin
    select top 1 * from Test_tbl where DateCol>getdate()
    set   @i   =   @i+1
end
-------------------------------------------------------------------------------------
select [语句执行时间(毫秒)]=datediff(ms, @d, getdate())
set nocount off
print ‘1000w数据 date 语句执行时间(毫秒):‘ + CONVERT(varchar(30), datediff(ms, @d, getdate()))

-- 测试性能2,int
-------------------------------------------------------------------------------------
set nocount on -- 不显示受影响行数
set   @i=0
while   @i <100
begin
    select top 1 * from Test_tbl where IntCol>20151212030303
    set   @i   =   @i+1
end
-------------------------------------------------------------------------------------
select [语句执行时间(毫秒)]=datediff(ms, @d, getdate())
set nocount off
print ‘1000w数据 int 语句执行时间(毫秒):‘ + CONVERT(varchar(30), datediff(ms, @d, getdate()))
时间: 2024-10-09 06:04:49

sql server 中 bigint 和 datetime 性能比较的相关文章

Java中的Date Time 与SQL Server 2005里的Datetime 之间的交互

Preface Environment:Platform: Windows XPLanguage: Java 1.5IDE: MyEclipse 6.0.1Database: SQL Server 2005 Enterprise en Introduction 本文主要讲述Java中的Date Time 与SQL Server 2005里的Datetime 如何进行交互.涉及到的Date Type有java.util.Datejava.sql.Datejava.sql.Timejava.sql.

为什么SQL语句Where 1=1 and在SQL Server中不影响性能

    最近一个朋友和我探讨关于Where 1=1 and这种形式的语句会不会影响性能.最后结论是不影响.     虽然结论正确,但对问题的认识却远远没有解决问题的根本.实际上在T-SQL语句的书写过程中经常犯得错误就是得出一个很窄的结论,然后教条式的奉若圣经,对于T-SQL领域来说,在网上经常可以看到所谓的优化守则,随便在网上搜了一些摘录如下: 不要有超过5个以上的表连接(JOIN) 考虑使用临时表或表变量存放中间结果 少用子查询 视图嵌套不要过深,一般视图嵌套不要超过2个为宜. 对出现在wh

SQL Server中使用Check约束提升性能

在SQL Server中,SQL语句的执行是依赖查询优化器生成的执行计划,而执行计划的好坏直接关乎执行性能. 在查询优化器生成执行计划过程中,需要参考元数据来尽可能生成高效的执行计划,因此元数据越多,则执行计划更可能会高效.所谓需要参考的元数据主要包括:索引.表结构.统计信息等,但还有一些不是很被注意的元数据,其中包括本文阐述的Check约束. 查询优化器在生成执行计划之前有一个阶段叫做代数树优化,比如说下面这个简单查询: 图1.简单查询 查询优化器意识到1=2这个条件是永远不相等的,因此不需要

SQL Server中一个隐性的IO性能杀手-Forwarded record

原文:SQL Server中一个隐性的IO性能杀手-Forwarded record 简介     最近在一个客户那里注意到一个计数器很高(Forwarded Records/Sec),伴随着间歇性的磁盘等待队列的波动.本篇文章分享什么是forwarded record,并从原理上谈一谈为什么Forwarded record会造成额外的IO.   存放原理     在SQL Server中,当数据是以堆的形式存放时,数据是无序的,所有非聚集索引的指针存放指向物理地址的RID.当数据行中的变长列增

SQL Server中多表连接时驱动顺序对性能的影响

原文:SQL Server中多表连接时驱动顺序对性能的影响 本文出处:http://www.cnblogs.com/wy123/p/7106861.html (保留出处并非什么原创作品权利,本人拙作还远远达不到,仅仅是为了链接到原文,因为后续对可能存在的一些错误进行修正或补充,无他) 最近在SQL Server中多次遇到开发人员提交过来的有性能问题的SQL,其表面的原因是表之间去的驱动顺序造成的性能问题,具体表现在(已排除其他因素影响的情况下),存储过程偶发性的执行时间超出预期,甚至在调试的时候

SQL Server 中VARCHAR(MAX)变量赋值引起的性能问题。

案例环境: 操作系统版本 : Windows Server 2008 R2 Standard  SP1 数据库版本   :  Microsoft SQL Server 2012 (SP1) - 11.0.3000.0 (X64) 案例介绍: 由于不能将生产环境的代码和数据贴上来,所以我构造了下面一个小案例,当然没法和生产环境的案例一致.只能是接近而已.但是足以反映问题本质就足够了. DROP TABLE ProductPrice;   GO   CREATE TABLE ProductPrice

SQL Server中提前找到隐式转换提升性能的办法

    http://www.cnblogs.com/shanksgao/p/4254942.html 高兄这篇文章很好的谈论了由于数据隐式转换造成执行计划不准确,从而造成了死锁.那如果在事情出现之前发现了这类潜在的风险岂不是更好?     那么我们来看一个简单的例子,如代码清单1所示.   1: SELECT * 2: FROM HumanResources.Employee 3: WHERE NationalIDNumber = 243322160 4:  5: SELECT * 6: FR

SQL Server中关于跟踪(Trace)那点事(转载)

前言 一提到跟踪俩字,很多人想到警匪片中的场景,同样在我们的SQL Server数据库中“跟踪”也是无处不在的,如果我们利用好了跟踪技巧,就可以针对某些特定的场景做定向分析,找出充足的证据来破案. 简单的举几个应用场景: 在线生产库为何突然宕机?数百张数据表为何不翼而飞?刚打好补丁的系统为何屡遭黑手?新添加的信息表为何频频丢失?某张表字段的突然更改,究竟为何人所为?这些个匿名的访问背后,究竟是人是鬼?突然增加的增量数据,究竟是对是错?数百兆的日志爆炸式的增长背后又隐藏着什么?这一且的背后,是应用

(4.7)怎么捕获和记录SQL Server中发生的死锁?

转自:https://blog.csdn.net/c_enhui/article/details/19498327 怎么捕获和记录SQL Server中发生的死锁? sql server如何让错误日志记录死锁 2014年02月19日 18:25:55 阅读数:1313 我们知道,可以使用SQL Server自带的Profiler工具来跟踪死锁信息.但这种方式有一个很大的敝端,就是消耗很大.据国外某大神测试,profiler甚至可以占到服务器总带宽的35%,所以,在一个繁忙的系统中,使用profi