代码改变世界

SQL Server解惑——为什么你的查询结果超出了查询时间范围

  潇湘隐者  阅读(1917)  评论(3编辑  收藏  举报

废话少说,直接上SQL代码(有兴趣的测试验证一下),下面这个查询语句为什么将2008-11-27的记录查询出来了呢?这个是同事遇到的一个问题,个人设计了一个例子。

 

USE AdventureWorks2014;
GO
SELECTFROM [Person].[Person]
WHERE ModifiedDate >= '2008-11-26 00:00:00:000'
  AND ModifiedDate <= '2008-11-26 23:59:59.999'

 

 

clip_image001

 

其实如果细看过文档的话,应该知道是什么原因,因为数据类型Datetiem的时间范围:00:00:00 到 23:59:59.997 , 最后部分的范围为0 ~997,官方文档提示,datetime的秒的小数部分精度的有舍入,具体请见下面

 

datetime 秒的小数部分精度的舍入

如下表所示,将 datetime 值舍入到 .000、.003、或 .007 秒的增量 。

用户指定的值

系统存储的值

01/01/98 23:59:59.999

1998-01-02 00:00:00.000

01/01/98 23:59:59.995

01/01/98 23:59:59.996

01/01/98 23:59:59.997

01/01/98 23:59:59.998

1998-01-01 23:59:59.997

01/01/98 23:59:59.992

01/01/98 23:59:59.993

01/01/98 23:59:59.994

1998-01-01 23:59:59.993

01/01/98 23:59:59.990

01/01/98 23:59:59.991

1998-01-01 23:59:59.990

 

实验测试验证,998会转换为997,而'2008-11-26 23:59:59.999'的话,就会转换为'2008-11-27 00:00:00.000',如下截图所示,所以尤其对数据精确性有要求的地方,要注意这些地方,否则SQL语句得出的结果在逻辑上就有误。

 

clip_image002

 

官方文档https://docs.microsoft.com/zh-cn/sql/t-sql/data-types/datetime-transact-sql?view=sql-server-ver15 中也有描述不准确的地方,如下截图所示: 

clip_image003

 

 

其实这个是精度问题,如果选择datetime2数据类型,它默认的小数精度更高,不会遇到这个问题,更多细节建议参考官方文档(下面参考资料)

 

 

 

参考资料:

 

https://docs.microsoft.com/zh-cn/sql/t-sql/data-types/datetime2-transact-sql?view=sql-server-ver15

https://docs.microsoft.com/zh-cn/sql/t-sql/data-types/datetime-transact-sql?view=sql-server-ver15

编辑推荐:
· 一个奇形怪状的面试题:Bean中的CHM要不要加volatile?
· [.NET]调用本地 Deepseek 模型
· 一个费力不讨好的项目,让我损失了近一半的绩效!
· .NET Core 托管堆内存泄露/CPU异常的常见思路
· PostgreSQL 和 SQL Server 在统计信息维护中的关键差异
阅读排行:
· DeepSeek “源神”启动!「GitHub 热点速览」
· 我与微信审核的“相爱相杀”看个人小程序副业
· 上周热点回顾(2.17-2.23)
· 如何使用 Uni-app 实现视频聊天(源码,支持安卓、iOS)
· 微软正式发布.NET 10 Preview 1:开启下一代开发框架新篇章
历史上的今天:
2016-11-10 ORA-00494: enqueue [CF] held for too long (more than 900 seconds) by 'inst 1, osid 5166'
2014-11-10 如何查看Oracle客户端版本
点击右上角即可分享
微信分享提示