2010-09-01 2 views
9

ho SQL Server 2005 Service Pack 2 standard 9.00.4053.00 (Intel X86)SQL Server: incuriosito da GETDATE()

Tabella ha quasi 30 milioni di righe ..

Se faccio

SELECT GETDATE(), * FROM 
<table> 

Identico valore di data e ora viene restituito compreso millisecondi parte .. se interrogazione ha preso più di 3 minuti per completare ...

Ho già letto

http://sqlblog.com/blogs/andrew_kelly/archive/2008/02/27/when-getdate-is-not-a-constant.aspx

http://social.msdn.microsoft.com/Forums/en-US/transactsql/thread/66507b8b-4a74-44c1-9637-3ab5f75db6a0

Uno dei link che ho postato (risposta marcata) suggeriscono che prima di SQL 2005 GETDATE era deterministico anche se SQL 2000 BOL afferma GETDATE è non deterministico

Se faccio un aggiornamento con milioni di righe

UPDATE tableName 
SET dateColumn = GETDATE() 

So che vuoi veramente fare

DECLARE @DT datetime 
SET @DT = GETDATE() 
UPDATE table 
SET datecol [email protected] 

Sono molto confuso

comportamento

quanto ci si aspetterebbe?

  1. In caso di select che ho postato in precedenza
  2. Comportamento di aggiornamento dichiarazione

Considerando che si sta updateing un datecolun su un tavolo con 100 milioni di righe Would datecolumn avrà la data identico e l'ora millisecondi ....?

risposta

3

In seguito alla risposta di Martin Smith, il determinismo cui si fa riferimento era un cambiamento nel comportamento di udf. In SQL Server 2000, non è possibile utilizzare GETDATE in un udf. È possibile in SQL Server 2005. See this link too

Come ha detto Martin Smith, alcune funzioni vengono valutate per colonna, per query. Non per riga. GETDATE è uno, RAND è un altro.

Se è necessario eseguire una valutazione riga per riga di GETDATE, quindi inserirlo in udf.

Edit:

NEWID è statisticamente unica. Deve essere valutato riga per riga in modo da non avere lo stesso valore visualizzato in un'altra riga. Quindi il trucco CHECKSUM(NEWID()) per generare numeri casuali riga per riga ...

+0

Grazie, ma perché non NEWID si comporta diversamente? selezionare Home 4 newid(), newid() da sys.objects – cshah

+0

Ora capisco come se si vuole restituire le righe in modo casuale poi ORDER BY NEWID() modo newid() è diverso ... – cshah

+0

Che cosa si comporterebbe l'aggiornamento stesso? vale a dire. UPDATE tableName SET dateColumn = GETDATE() OK sarà lo stesso .. stupido :-( – cshah

10

GetDate() non è mai stato deterministico. Deterministico significa che restituirà sempre lo stesso risultato quando ha passato gli stessi parametri.

In comune con rand() Viene valutato una volta per colonna ma una volta valutato rimane lo stesso per tutte le righe.

E 'più facile vedere questo comportamento con rand() di getdate()

select top 4 rand(), rand() 
from sys.objects 

restituito

---------------------- ---------------------- 
0.0566172633850772  0.431111195699363 
0.0566172633850772  0.431111195699363 
0.0566172633850772  0.431111195699363 
0.0566172633850772  0.431111195699363 

Se si tenta il seguente

select top 10 getdate(), getdate() 
from sys.objects 

e guardano le proprietà dell'operatore ComputeScalar a il piano di esecuzione effettivo vedrai tha t GetDate() viene valutato due volte.

NB: È possibile che questo comportamento di valutazione per colonna anziché per query sia cambiato dopo SQL 2000 (non so) ma non è ciò che BOL definisce come il significato di deterministico.

+0

Martin, grazie ... – cshah

+0

Martin, come mai NEWID() restituisce un risultato diverso? – cshah

+0

@cshah - Buona domanda e una non so la risposta! –