Comment faire pour retourner la partie date seulement à partir d'un Serveur SQL de type de données datetime

Question

SELECT GETDATE()

Retourne: 2008-09-22 15:24:13.790

Je veux que la date de la partie, sans le temps de la partie: 2008-09-22 00:00:00.000

Answer 1

SELECT DATEADD(dd, 0, DATEDIFF(dd, 0, @your_date))

par exemple

SELECT DATEADD(dd, 0, DATEDIFF(dd, 0, GETDATE()))

donne-moi

2008-09-22 00:00:00.000

Pour:

• Pas de varchar<->datetime conversions requises
• Pas besoin de réfléchir sur les paramètres régionaux

Answer 2

SQLServer 2008 a maintenant une Date de type de données qui contient uniquement une date avec un rien de temps. Quelqu'un à l'aide de sql server 2008 et au-delà de pouvez effectuer les opérations suivantes:

select CONVERT(date, getdate())

Answer 3

Pourquoi ne pas simplement

select cast(getdate() as date)

?

Answer 4

DATEADD et DATEDIFF sont mieux que d'opter pour le type varchar. Les deux requêtes ont le même plan d'exécution, mais les plans d'exécution sont essentiellement sur les données des stratégies d'accès et ne révèlent pas toujours implicite des coûts impliqués dans la CPU a pris le temps d'effectuer toutes les pièces. Si les deux requêtes sont exécutées sur une table avec des millions de lignes, le temps de calcul à l'aide de DateDiff peut être proche de 1/3ème de la Convertir en temps CPU!

Pour voir les plans d'exécution des requêtes:

set showplan_text on
GO 

Les deux DATEADD et DATEDIFF exécuter une CONVERT_IMPLICIT.

Bien que l'CONVERTIR solution est plus simple et plus facile à lire pour certains, il est plus lent. Il n'est pas nécessaire de jeter en arrière pour datetime (ce qui est implicitement fait par le serveur). Il ya aussi pas de réel besoin dans les DateDiff méthode pour DateAdd par la suite comme le résultat sous forme d'entier sera également implicitement converti en arrière de type datetime.

---

SÉLECTIONNEZ CONVERT(varchar, Madate, 101) DE DatesTable

  |--Compute Scalar(DEFINE:([Expr1004]=CONVERT(varchar(30),[TEST].[dbo].[DatesTable].[MyDate],101)))
       |--Table Scan(OBJECT:([TEST].[dbo].[DatesTable]))

---

SÉLECTIONNEZ DATEADD(dd, 0, DATEDIFF(dd, 0, Madate)) à PARTIR de DatesTable

  |--Compute Scalar(DEFINE:([Expr1004]=dateadd(day,(0),CONVERT_IMPLICIT(datetime,datediff(day,'1900-01-01 00:00:00.000',CONVERT_IMPLICIT(datetime,[TEST].[dbo].[DatesTable].[MyDate],0)),0))))
       |--Table Scan(OBJECT:([TEST].[dbo].[DatesTable]))

L'utilisation de FLOOR () @digi a des performances plus proches de DateDiff, mais n'est pas recommandé que le moulage du type de données datetime à flotter et à l'arrière ne donnent pas toujours de la valeur d'origine.

Rappelez-vous les gars: Ne croyez pas les personnes. Regardez les statistiques de performances, et de le tester vous-même!

Soyez prudent lorsque vous testez vos résultats. La sélection de plusieurs lignes pour le client permet de masquer la différence de performances car il faut plus de temps pour envoyer les lignes sur le réseau qu'il n'en faut pour effectuer les calculs. Donc, assurez-vous que le travail pour toutes les lignes est effectué par le serveur, mais il n'est pas un ensemble de lignes envoyées au client.

Il semble y avoir confusion pour certaines personnes environ lorsque le cache d'optimisation affecte les requêtes. L'exécution de deux requêtes dans le même lot ou en lots séparés n'a pas d'effet sur la mise en cache. De sorte que vous pouvez expirer le cache manuellement, ou tout simplement d'exécuter les requêtes en arrière et en avant à plusieurs reprises. Tout d'optimisation de requête #2 aura aussi une incidence sur toutes les requêtes suivantes, afin de jeter l'exécution #1 si vous le souhaitez.

Ici est plein de script de test de performance et de résultats qui prouvent DateDiff est considérablement plus rapide que la conversion de type varchar.

Answer 5

Simple et T-SQL conforme:

CAST(GETDATE() AS DATE)