Il miglior approccio per rimuovere parte del tempo di datetime in SQL Server

Quale metodo offre le migliori prestazioni quando si rimuove la porzione di tempo da un campo datetime in SQL Server?

a) select DATEADD(dd, DATEDIFF(dd, 0, getdate()), 0)

o

b) select cast(convert(char(11), getdate(), 113) as datetime)

Il secondo metodo invia alcuni byte in più in entrambi i modi, ma potrebbe non essere importante quanto la velocità della conversione.

Entrambi sembrano essere molto veloci, ma potrebbe esserci una differenza di velocità quando si affrontano centinaia di migliaia o più righe?

Inoltre, è possibile che ci siano metodi ancora migliori per sbarazzarsi della porzione di tempo di un datetime in SQL?

Rigorosamente, il metodo richiede ameno risorse:

a) select DATEADD(dd, DATEDIFF(dd, 0, getdate()), 0)

Dimostrato meno utilizzo della CPU per la stessa durata totale di un milione di righe da parte di qualcuno con troppo tempo a disposizione: il modo più efficiente in SQL Server per ottenere la data da data + ora?

Ho visto un test simile altrove con risultati simili.

Preferisco il DATEADD / DATEDIFF perché:

• varchar è soggetto a problemi di lingua / formato data
  Esempio: Perché la mia espressione CASE non è deterministica?
• float si basa sulla memoria interna
• si estende al primo giorno del mese, domani ecc. cambiando la base "0"

Modifica, ottobre 2011

Per SQL Server 2008+, è possibile eseguire il CAST su dateie CAST(getdate() AS date). O semplicemente usa il datetipo di dati, quindi non c'è tempo per rimuoverlo.

Modifica, gennaio 2012

Un esempio esaustivo di quanto sia flessibile: è necessario calcolare in base al tempo arrotondato o alla data nel server sql

Modifica, maggio 2012

Non utilizzarlo nelle clausole WHERE e simili senza pensare: l'aggiunta di una funzione o CAST a una colonna invalida l'utilizzo dell'indice. Vedi il numero 2 qui: http://www.simple-talk.com/sql/t-sql-programming/ten-common-sql-programming-mistakes/

Ora, questo ha un esempio di versioni successive dell'ottimizzatore di SQL Server che gestiscono correttamente CAST fino ad oggi, ma generalmente sarà una cattiva idea ...

Modifica, settembre 2018, per datetime2

DECLARE @datetime2value datetime2 = '02180912 11:45' --this is deliberately within datetime2, year 0218
DECLARE @datetime2epoch datetime2 = '19000101'

select DATEADD(dd, DATEDIFF(dd, @datetime2epoch, @datetime2value), @datetime2epoch)

In SQL Server 2008 è possibile utilizzare:

CONVERT(DATE, getdate(), 101)

Naturalmente questo è un vecchio thread ma per completarlo.

Da SQL 2008 è possibile utilizzare il tipo di dati DATE in modo da poter semplicemente fare:

SELECT CONVERT(DATE,GETDATE())

SELECT CAST(FLOOR(CAST(getdate() AS FLOAT)) AS DATETIME)

... non è una buona soluzione, per i commenti qui sotto.

Vorrei eliminare questa risposta, ma la lascerò qui come controesempio poiché ritengo che la spiegazione dei commentatori sul perché non sia una buona idea sia ancora utile.

In SQL Server 2008 esiste un tipo di dati DATE (anche un tipo di dati TIME).

CAST(GetDate() as DATE)

o

declare @Dt as DATE = GetDate()

Ecco un'altra risposta, da un'altra domanda duplicata:

SELECT CAST(CAST(getutcdate() - 0.50000004 AS int) AS datetime) 

Questo metodo di numeri magici si comporta leggermente più velocemente del metodo DATEADD. (Sembra ~ 10%)

Il tempo della CPU su diversi round di un milione di record:

DATEADD   MAGIC FLOAT
500       453
453       360
375       375
406       360

Ma nota che questi numeri sono probabilmente irrilevanti perché sono già MOLTO veloci. A meno che non avessi set di record di 100.000 o più, non riuscivo nemmeno a leggere il Tempo CPU sopra lo zero.

Considerando il fatto che DateAdd è pensato per questo scopo ed è più robusto, direi che usi DateAdd.

SELECT CAST(CAST(GETDATE() AS DATE) AS DATETIME)

Mi piace molto:

[date] = CONVERT(VARCHAR(10), GETDATE(), 120)

Il 120codice del formato forzerà la data nello standard ISO 8601:

'YYYY-MM-DD' or '2017-01-09'

Super facile da usare in dplyr ( R) e Panda ( Python)!

ATTENZIONE!

Il metodo a) eb) NON ha sempre lo stesso output!

select DATEADD(dd, DATEDIFF(dd, 0, '2013-12-31 23:59:59.999'), 0)

Produzione: 2014-01-01 00:00:00.000

select cast(convert(char(11), '2013-12-31 23:59:59.999', 113) as datetime)

Produzione: 2013-12-31 00:00:00.000

(Testato su MS SQL Server 2005 e 2008 R2)

EDIT: Secondo il commento di Adam, questo non può accadere se leggi il valore della data dalla tabella, ma può accadere se fornisci il valore della tua data come un valore letterale (esempio: come parametro di una procedura memorizzata chiamata via ADO.NET).

In primo luogo, ridurre il tempo sugli inserti / gli aggiornamenti. Per quanto riguarda la conversione al volo, nulla può battere una funzione definita dall'utente in termini di manutenzione:

select date_only(dd)

L'implementazione di date_onlypuò essere qualsiasi cosa ti piaccia - ora è stata sottratta e il codice chiamante è molto più pulito.

Vedi questa domanda:
Come posso troncare un datetime in SQL Server?

Qualunque cosa tu faccia, non usare il metodo stringa . Questo è il modo peggiore in cui potresti farlo.

Ho già risposto, ma lo ammetterò anche là ... anche questo si preforma bene, ma funziona eliminando il decimale (che memorizza il tempo) dal float e restituendo solo una parte intera (che è la data)

 CAST(
FLOOR( CAST( GETDATE() AS FLOAT ) )
AS DATETIME
)

la seconda volta che ho trovato questa soluzione ... ho preso questo codice

CAST(round(cast(getdate()as real),0,1) AS datetime)

Questo metodo non utilizza la funzione stringa. Dateè fondamentalmente un tipo di dati reale con cifre prima che i decimali siano la frazione di un giorno.

questo immagino sarà più veloce di molto.

Per me il codice qui sotto è sempre un vincitore:

SELECT CONVERT(DATETIME, FLOOR(CONVERT(FLOAT,GETDATE())));

seleziona CONVERT (char (10), GetDate (), 126)

Penso che tu intenda cast(floor(cast(getdate()as float))as datetime)

real è solo a 32 bit e potrebbe perdere alcune informazioni

Questo è il più veloce cast(cast(getdate()+x-0.5 as int)as datetime)

... anche se solo circa il 10% più veloce(about 0.49 microseconds CPU vs. 0.58)

Questo è stato raccomandato e richiede lo stesso tempo nel mio test proprio ora: DATEADD(dd, DATEDIFF(dd, 0, getdate()), 0)

In SQL 2008, la funzione CLR di SQL è circa 5 volte più veloce rispetto all'utilizzo di una funzione SQL, a 1,35 microsecondi rispetto a 6,5 ​​microsecuzioni, indicando un overhead di chiamata di funzione molto più basso per una funzione CLR SQL rispetto a un semplice UDF SQL.

In SQL 2005, la funzione CLR di SQL è 16 volte più veloce, secondo i miei test, rispetto a questa funzione lenta:

create function dateonly (  @dt datetime )
returns datetime
as
begin
return cast(floor(cast(@dt as float))as int)
end

Che ne dici select cast(cast my_datetime_field as date) as datetime)? Ciò si traduce nella stessa data, con l'ora impostata su 00:00, ma evita qualsiasi conversione in testo ed evita anche qualsiasi arrotondamento numerico esplicito.

Penso che se ti attieni rigorosamente a TSQLquesto è il modo più veloce per troncare il tempo:

 select convert(datetime,convert(int,convert(float,[Modified])))

Ho trovato questo metodo di troncamento più veloce di circa il 5% rispetto al DateAddmetodo. E questo può essere facilmente modificato per arrotondare al giorno più vicino in questo modo:

select convert(datetime,ROUND(convert(float,[Modified]),0))

Qui ho creato una funzione per rimuovere alcune parti di un datetime per SQL Server. Uso:

• Il primo parametro è il datetime da rimuovere.
• Il secondo parametro è un carattere:
  • s: round a secondi; rimuove i millisecondi
  • m: giri a minuti; rimuove secondi e millisecondi
  • h: round a ore; rimuove minuti, secondi e millisecondi.
  • d: giri a giorni; rimuove ore, minuti, secondi e millisecondi.
• Restituisce il nuovo datetime

create function dbo.uf_RoundDateTime(@dt as datetime, @part as char) returns datetime as begin if CHARINDEX( @part, 'smhd',0) = 0 return @dt; return cast( Case @part when 's' then convert(varchar(19), @dt, 126) when 'm' then convert(varchar(17), @dt, 126) + '00' when 'h' then convert(varchar(14), @dt, 126) + '00:00' when 'd' then convert(varchar(14), @dt, 112) end as datetime ) end

Nel caso in cui qualcuno stia cercando una versione di Sybase poiché molte delle versioni precedenti non hanno funzionato

CAST(CONVERT(DATE,GETDATE(),103) AS DATETIME)

• Testato in I SQL v11 in esecuzione su Adaptive Server 15.7

Se possibile, per cose speciali come questa, mi piace usare le funzioni CLR.

In questo caso:

[Microsoft.SqlServer.Server.SqlFunction]
    public static SqlDateTime DateOnly(SqlDateTime input)
    {
        if (!input.IsNull)
        {
            SqlDateTime dt = new SqlDateTime(input.Value.Year, input.Value.Month, input.Value.Day, 0, 0, 0);

            return dt;
        }
        else
            return SqlDateTime.Null;
    }

Personalmente, uso quasi sempre le funzioni definite dall'utente per questo se ho a che fare con SQL Server 2005 (o versione precedente), tuttavia, va notato che ci sono degli svantaggi specifici nell'uso di UDF, specialmente se applicati alle clausole WHERE (vedi sotto e i commenti su questa risposta per ulteriori dettagli). Se si utilizza SQL Server 2008 (o versioni successive), vedere di seguito.

In effetti, per la maggior parte dei database che creo, aggiungo questi UDF proprio all'inizio, poiché so che prima o poi ne avrò bisogno al 99%.

Ne creo uno per "solo data" e "solo tempo" (anche se quello "solo data" è di gran lunga il più utilizzato dei due).

Ecco alcuni link a una varietà di UDF relativi alla data:

Funzioni essenziali per data, ora e data di SQL Server Funzione
get only date

L'ultimo link mostra non meno di 3 modi diversi per ottenere la data solo parte di un campo datetime e menziona alcuni pro e contro di ogni approccio.

Se si utilizza un UDF, si dovrebbe notare che si dovrebbe cercare di evitare di utilizzare l'UDF come parte di una clausola WHERE in una query poiché ciò ostacolerebbe notevolmente le prestazioni della query. Il motivo principale di ciò è che l'utilizzo di un UDF in una clausola WHERE rende tale clausola come non eseguibile , il che significa che SQL Server non può più utilizzare un indice con quella clausola al fine di migliorare la velocità di esecuzione della query. Con riferimento al mio uso personale di UDF, userò spesso la colonna della data "non elaborata" all'interno della clausola WHERE, ma applicherò l'UDF alla colonna SELECT. In questo modo, l'UDF viene applicato solo al set di risultati filtrati e non a tutte le righe della tabella come parte del filtro.

Naturalmente, l' approccio migliore in assoluto per questo è utilizzare SQL Server 2008 (o versioni successive) e separare le date e gli orari , poiché il motore di database di SQL Server fornisce quindi in modo nativo i singoli componenti di data e ora e può interrogarli in modo efficiente in modo indipendente senza la necessità di un UDF o altro meccanismo per estrarre la parte di data o ora da un tipo di data e ora composito.

Io userei:

CAST
(
CAST(YEAR(DATEFIELD) as varchar(4)) + '/' CAST(MM(DATEFIELD) as varchar(2)) + '/' CAST(DD(DATEFIELD) as varchar(2)) as datetime
) 

Creando così un nuovo campo in modo efficace dal campo data che hai già.