廢話少說，直接上SQL代碼（有興趣的測試驗證一下），下麵這個查詢語句為什麼將2008-11-27的記錄查詢出來了呢？這個是同事遇到的一個問題，個人設計了一個例子。 USE AdventureWorks2014;GOSELECT * FROM [Person].[Person]WHERE Modifi... ...
廢話少說，直接上SQL代碼（有興趣的測試驗證一下），下麵這個查詢語句為什麼將2008-11-27的記錄查詢出來了呢？這個是同事遇到的一個問題，個人設計了一個例子。
USE AdventureWorks2014;GOSELECT * FROM [Person].[Person]
WHERE ModifiedDate >= '2008-11-26 00:00:00:000'
AND ModifiedDate <= '2008-11-26 23:59:59.999'
其實如果細看過文檔的話，應該知道是什麼原因，因為數據類型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 |
1998-01-01 23:59:59.997 |
|
01/01/98 23:59:59.992 |
1998-01-01 23:59:59.993 |
|
01/01/98 23:59:59.990 |
1998-01-01 23:59:59.990 |
實驗測試驗證，998會轉換為997，而'2008-11-26 23:59:59.999'的話，就會轉換為'2008-11-27 00:00:00.000'，如下截圖所示，所以尤其對數據精確性有要求的地方，要註意這些地方，否則SQL語句得出的結果在邏輯上就有誤。
官方文檔https://docs.microsoft.com/zh-cn/sql/t-sql/data-types/datetime-transact-sql?view=sql-server-ver15 中也有描述不准確的地方，如下截圖所示：
其實這個是精度問題，如果選擇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
