datetime2(0) 與 datetime2(2)
儲存大小
6 個字節，精度小於 3。7
個字節，精度 3 和 4。
所有其他精度需要 8 個字節。
datetime2(0),datetime2(1)的大小datetime2(2)使用相同的儲存量（6 字節）。我是否可以正確地說我也可以
datetime2(2)在沒有任何額外尺寸成本的情況下獲得精度的好處？請注意：
- 該列與PK建立索引，形成複合聚集索引（用於表分區）
- 我不在乎毫秒
datetime2(0)在 where 子句中使用或通過索引查找時 CPU 效率會更高嗎？這是一個巨大的表，所以最小的優化會產生很大的不同。
dateTime2(0)、dateTime2(1)、dateTime2(2)、dateTime2(3) 的大小使用相同的儲存量。（6 字節）
我是否可以正確地說我也可以使用 dateTime2(3) 並在不增加任何額外尺寸成本的情況下獲得精度的好處。
不，您誤解了文件。請注意，文件聲明精度小於3的**儲存大小為 6 個字節（強調我的）。所以精度等於 3 將需要 7 個字節。
如果您不關心毫秒，
datetime2(0)那將是正確的數據類型和精度。最佳實踐是根據儲存的數據指定適當的數據類型和精度，因為這將固有地提供最佳儲存和效率。話雖如此，只要儲存大小相同，我預計不會對指定的 datetime2 精度產生顯著的性能影響，但我自己沒有專門測試過。當源中可用的精度更高時，應用程序要求將規定必須在數據庫中儲存什麼。例如，對於來自 的訂單輸入時間
SYSDATETIME()，使用者可能不想要 100 納秒的精度。再次，根據需求為新開發選擇數據類型和精度，通常無需額外考慮即可獲得最佳性能：
- 日期- 你不需要時間
- smalldatetime - 你不需要秒
- datetime2(0) - 你不需要小數秒
- datetime2(1-7) - 您需要指定精度的小數秒
- datetimeoffset(0-7) - 您需要具有時區意識的日期和時間
- time(0-7) - 您只需要指定精度的小數秒時間（無日期）
儘管 datetime2 最適合上面列出的新開發，但有時可能需要使用datetime（固定精度 3，精度為 1/300 小數秒）來與舊版 datetime 應用程序兼容，從而避免隱式轉換和意外比較行為，但在以小數秒精度和增加儲存為代價。
考慮到儲存比所需精度更高的精度也可能會產生開發成本。如果在只需要整秒精度的情況下儲存帶有小數秒的時間分量，查詢仍然需要考慮小數秒以返回正確的結果。例如，對於使用者通過僅允許整秒的 UI 選擇時間範圍的應用程序，應用程式碼需要考慮結束時間範圍值中的小數秒並相應地調整使用者提供的值（例如
WHERE OrderEntryTime BETWEEN '2017-01-11T08:00:00.00.00' AND '2017-01-11T08:59:59.99'或WHERE OrderEntryTime >= '2017-01-11T08:00:00.00' AND OrderEntryTime < '2017-01-11T09:00:00.00'）。這將增加程式碼的複雜性。