即使在幾年后，這仍然會不斷地增加選票，所以我需要為SQLServer的現(xiàn)代版本更新它。對于SQLServer 2008及更高版本，它很簡單：
cast(getDate() As Date)
請注意，底部附近的最后三段仍然適用，您通常需要后退一步，并找到一種方法來避免第一時間的轉(zhuǎn)換。
但也有其他方法可以實現(xiàn)這一點。以下是最常見的。
正確的方法(自SQLServer 2008以來新的)：
cast(getdate() As Date)
正確的方式(舊的)：
dateadd(dd, datediff(dd,0, getDate()), 0)
這是舊的，但它仍然值得知道，因為它也可以很容易地適應其他時間點，如一個月的第一分鐘，小時，或年。
這種正確的方法使用作為Ansi標準一部分的文檔化的函數(shù)，并保證它們能夠正常工作，但它可能會稍微慢一些。它的工作原理是找出從第0天到今天有多少天，并把這幾天加到第0天。無論您的日期時間是如何存儲的，無論您的地區(qū)是什么，它都會工作。
快速方式：
cast(floor(cast(getdate() as float)) as datetime)
這是因為Datetime列存儲為8字節(jié)二進制值。將它們拋到浮點，使其底部移除該分數(shù)，當您將它們轉(zhuǎn)換回DateTime時，值的時間部分就會消失。這只是一點點的變化，沒有復雜的邏輯，而且非常快地。
請注意，這依賴于實現(xiàn)細節(jié)，Microsoft可以隨時更改，甚至在自動服務(wù)更新中也是如此。它也不是很便攜。在實踐中，這種實現(xiàn)不太可能很快改變，但是如果您選擇使用它，仍然需要意識到它的危險。既然我們可以選擇約會，那就沒什么必要了。
錯誤的方式：
cast(convert(char(11), getdate(), 113) as datetime)
錯誤的工作方式是轉(zhuǎn)換為字符串、截斷字符串并將其轉(zhuǎn)換回日期時間。它是不對，原因有兩個：1)它可能不適用于所有的地區(qū)；2)它是最慢的方法來實現(xiàn)這一點.而不只是一點點，它就像一個數(shù)量級或兩個數(shù)量級比其他選項慢。
更新最近，這獲得了一些選票，因此我想補充一點，自從我發(fā)布這篇文章以來，我看到了一些非常確鑿的證據(jù)，表明SQL Server將優(yōu)化“正確”方式和“快速”方法之間的性能差異，這意味著您現(xiàn)在應該更喜歡前者。
不管是哪種情況，你都想寫您的查詢，以避免在第一時間這樣做。..在數(shù)據(jù)庫上做這項工作是非常罕見的。
在大多數(shù)地方，數(shù)據(jù)庫已經(jīng)成為您的瓶頸。通常，服務(wù)器是增加硬件以提高性能最昂貴的服務(wù)器，也是最難實現(xiàn)這些添加的服務(wù)器(例如，您必須平衡磁盤和內(nèi)存)。從技術(shù)和業(yè)務(wù)角度來看，向外擴展也是最困難的；在技術(shù)上添加Web或應用程序服務(wù)器要比添加數(shù)據(jù)庫服務(wù)器容易得多，即使這是錯誤的，IIS或Apache也不會為每個服務(wù)器許可證支付20，000美元以上的費用。
我想指出的一點是，只要有可能，您就應該在應用程序級別完成這項工作。這個只當您需要按日分組時，您應該發(fā)現(xiàn)自己截斷了SQLServer上的日期時間，即使這樣，您也應該將一個額外的列設(shè)置為計算列，在插入/更新時維護，或者在應用程序邏輯中維護。把這個破壞索引的，CPU繁重的工作從你的數(shù)據(jù)庫中拿出來。
