table_hint (Transact-SQL)
Data aggiornamento: 12 dicembre 2006
Specifica che Query Optimizer utilizzerà una scansione di tabella, uno o più indici oppure un metodo di blocco con questa tabella o vista e per questa istruzione SELECT, INSERT, UPDATE o DELETE. Sebbene ciò sia facoltativo, Query Optimizer può in genere scegliere il metodo di ottimizzazione migliore senza che siano specificati hint.
Importante: |
---|
Poiché Query Optimizer di SQL Server 2005 in genere seleziona il piano di esecuzione migliore per una query, gli hint, compreso <table_hint>, devono essere utilizzati solo se strettamente necessario e sempre da sviluppatori e amministratori di database esperti. |
Si applica a:
Convenzioni della sintassi Transact-SQL
Sintassi
<table_hint> ::=
[ NOEXPAND ] {
INDEX ( index_val [ ,...n ] )
| FASTFIRSTROW
| HOLDLOCK
| NOLOCK
| NOWAIT
| PAGLOCK
| READCOMMITTED
| READCOMMITTEDLOCK
| READPAST
| READUNCOMMITTED
| REPEATABLEREAD
| ROWLOCK
| SERIALIZABLE
| TABLOCK
| TABLOCKX
| UPDLOCK
| XLOCK
}
<table_hint_limited> ::=
{
KEEPIDENTITY
| KEEPDEFAULTS
| FASTFIRSTROW
| HOLDLOCK
| IGNORE_CONSTRAINTS
| IGNORE_TRIGGERS
| NOWAIT
| PAGLOCK
| READCOMMITTED
| READCOMMITTEDLOCK
| READPAST
| REPEATABLEREAD
| ROWLOCK
| SERIALIZABLE
| TABLOCK
| TABLOCKX
| UPDLOCK
| XLOCK
}
Argomenti
- NOEXPAND
Specifica che qualsiasi vista indicizzata non venga espansa per accedere alle tabelle sottostanti quando Query Optimizer elabora la query. In Query Optimizer la vista viene gestita come una tabella con indici cluster. L'hint NOEXPAND è applicabile solo alle viste indicizzate. Per ulteriori informazioni, vedere la sezione Osservazioni.
INDEX ( index_val [ ,... n ] )
Specifica il nome o l'ID degli indici che devono essere utilizzati da Query Optimizer quando viene elaborata l'istruzione. È possibile specificare solo un hint per l'indice per ogni tabella.Se esiste un indice cluster, INDEX(0) attiva una scansione degli indici cluster, mentre INDEX(1) esegue una scansione o una ricerca degli indici cluster. Se non esiste alcun indice cluster, INDEX(0) attiva una scansione di tabella, mentre INDEX(1) viene interpretato come errore.
La sintassi alternativa INDEX = specifica un unico hint per l'indice. Questa funzionalità è disponibile per compatibilità con le versioni precedenti.
Se nell'elenco di hint vengono indicati più indici, gli indici duplicati vengono ignorati, mentre gli altri indici vengono utilizzati per il recupero delle righe della tabella. L'ordine degli indici nell'hint è significativo. Un hint per indici multipli impone inoltre il collegamento degli indici tramite AND e per ogni indice a cui si accede viene applicato il numero massimo possibile di condizioni. Se l'insieme di indici dell'hint non è sufficiente, dopo il recupero di tutte le colonne indicizzate da parte di Motore di database di SQL Server 2005 viene eseguita un'operazione di recupero di riga.
[!NOTA] Se in una tabella dei fatti in un join a stella viene utilizzato un hint per l'indice che fa riferimento a più indici, l'hint per l'indice viene ignorato e verrà restituito un messaggio di avviso. Non è inoltre consentito il collegamento degli indici tramite OR per una tabella per la quale è stato specificato un hint per l'indice.
Un hint di tabella può includere al massimo 250 indici non cluster.
KEEPIDENTITY
Applicabile solo in un'istruzione INSERT se viene utilizzata l'opzione BULK con OPENROWSET.Specifica che i valori Identity presenti nel file di dati importato devono essere utilizzati per la colonna Identity. Se KEEPIDENTITY viene omesso, i valori Identity per questa colonna vengono verificati ma non importati e Query Optimizer assegna automaticamente valori univoci in base ai valori di inizializzazione e di incremento specificati in fase di creazione della tabella.
Importante: Se il file di dati non contiene valori per la colonna Identity nella tabella o vista, è necessario ignorare la colonna Identity a meno che questa non sia l'ultima colonna della tabella. Per ulteriori informazioni, vedere Utilizzo di un file di formato per escludere un campo di dati. Se una colonna Identity viene ignorata correttamente, Query Optimizer assegna automaticamente valori univoci per la colonna Identity nelle righe importate della tabella. Per un esempio di utilizzo di questo hint in un'istruzione INSERT ... SELECT * FROM OPENROWSET(BULK...), vedere Mantenimento dei valori Identity durante l'importazione di massa dei dati.
Per ulteriori informazioni sul controllo del valore Identity per una tabella, vedere DBCC CHECKIDENT (Transact-SQL).
KEEPDEFAULTS
Applicabile solo in un'istruzione INSERT se viene utilizzata l'opzione BULK con OPENROWSET.Specifica l'inserimento di un eventuale valore predefinito della colonna della tabella anziché NULL quando nel record di dati non è presente un valore per la colonna.
Per un esempio di utilizzo di questo hint in un'istruzione INSERT ... SELECT * FROM OPENROWSET(BULK...), vedere Mantenimento dei valori Null o utilizzo dei valori predefiniti durante un'importazione di massa.
- FASTFIRSTROW
Equivale a OPTION (FAST 1). Per ulteriori informazioni, vedere FAST nella clausola OPTION in SELECT.
- HOLDLOCK
Equivale a SERIALIZABLE. Per ulteriori informazioni, vedere la sezione SERIALIZABLE di seguito in questo argomento. HOLDLOCK si applica solo alla tabella o alla vista per la quale è stato specificato e solo per la durata della transazione definita dall'istruzione in cui è utilizzato. Non è possibile utilizzare l'argomento HOLDLOCK in un'istruzione SELECT che include l'opzione FOR BROWSE.
IGNORE_CONSTRAINTS
Applicabile solo in un'istruzione INSERT se viene utilizzata l'opzione BULK con OPENROWSET.Specifica che qualsiasi vincolo sulla tabella verrà ignorato dall'operazione di importazione di massa. Per impostazione predefinita, l'istruzione INSERT controlla i vincoli CHECK e FOREIGN KEY. Se si specifica IGNORE_CONSTRAINTS per un'operazione di importazione di massa, l'istruzione INSERT deve ignorare tali vincoli in una tabella di destinazione. Si noti che non è possibile disattivare i vincoli UNIQUE, PRIMARY KEY o NOT NULL.
Una situazione in cui potrebbe essere utile disattivare i vincoli CHECK e FOREIGN KEY è quando i dati di input contengono righe che violano i vincoli. Disattivando i vincoli CHECK e FOREIGN KEY, è possibile importare i dati e quindi utilizzare istruzioni Transact-SQL per pulire i dati.
Si noti, tuttavia, che quando i vincoli CHECK e FOREIGN KEY vengono ignorati, dopo l'operazione ogni vincolo ignorato nella tabella viene contrassegnato come is_not_trusted nella vista del catalogo sys.check_constraints o sys.foreign_keys. In un determinato momento sarà necessario controllare i vincoli sull'intera tabella. Se la tabella non è vuota prima dell'operazione di importazione di massa, l'impegno per la riconvalida dei vincoli può essere superiore all'impegno per l'applicazione dei vincoli CHECK e FOREIGN KEY ai dati incrementali.
IGNORE_TRIGGERS
Applicabile solo in un'istruzione INSERT se viene utilizzata l'opzione BULK con OPENROWSET.Specifica che qualsiasi trigger definito sulla tabella verrà ignorato dall'operazione di importazione di massa. Per impostazione predefinita, l'istruzione INSERT applica i trigger.
Utilizzare l'argomento IGNORE_TRIGGERS solo se l'applicazione non dipende dai trigger e l'ottimizzazione delle prestazioni è un fattore importante.
- NOLOCK
Equivale a READUNCOMMITTED. Per ulteriori informazioni, vedere la sezione READUNCOMMITTED di seguito in questo argomento.
- NOWAIT
Imposta Motore di database di SQL Server 2005 in modo che restituisca un messaggio non appena viene rilevato un blocco nella tabella. NOWAIT equivale a specificare SET LOCK_TIMEOUT 0 per una tabella specifica.
- PAGLOCK
Acquisisce i blocchi di pagina dove in genere vengono acquisiti i singoli blocchi su righe o chiavi oppure dove in genere viene acquisito un singolo blocco a livello di tabella. Per impostazione predefinita, viene utilizzato la modalità di blocco appropriata per l'operazione specifica. Se viene specificato nelle transazioni operative al livello di isolamento SNAPSHOT, i blocchi di pagina vengono acquisiti solo se PAGLOCK è combinato con altri hint di tabella che richiedono i blocchi, ad esempio UPDLOCK e HOLDLOCK.
- READCOMMITTED
Specifica la conformità delle operazioni di lettura con le regole relative al livello di isolamento READ COMMITTED mediante l'utilizzo dei blocchi o del controllo delle versioni delle righe. Se l'opzione di database READ_COMITTED_SNAPSHOT è impostata su OFF, Motore di database acquisisce i blocchi condivisi durante la lettura dei dati e li rilascia al completamento dell'operazione di lettura. Se l'opzione di database READ_COMMITTED_SNAPSHOT è impostata su ON, Motore di database non acquisisce i blocchi e utilizza il controllo delle versioni delle righe. Per ulteriori informazioni sui livelli di isolamento, vedere SET TRANSACTION ISOLATION LEVEL (Transact-SQL).
- READCOMMITTEDLOCK
Specifica la conformità delle operazioni di lettura con le regole relative al livello di isolamento READ COMMITTED mediante l'utilizzo dei blocchi. Motore di database acquisisce i blocchi condivisi durante la lettura dei dati e li rilascia al completamento dell'operazione di lettura indipendentemente dalle impostazioni dell'opzione di database READ_COMMITTED_SNAPSHOT. Per ulteriori informazioni sui livelli di isolamento, vedere SET TRANSACTION ISOLATION LEVEL (Transact-SQL).
READPAST
Specifica che il Motore di database non leggerà le righe bloccate da altre transazioni. Nella maggior parte delle circostanze, ciò è applicabile anche alle pagine. Motore di database ignora le righe o le pagine anziché bloccare la transazione corrente finché i blocchi non vengono rilasciati. L'argomento READPAST può essere specificato solo nelle transazioni operative ai livelli di isolamento READ COMMITTED o REPEATABLE READ. Se viene specificato nelle transazioni operative al livello di isolamento SNAPSHOT, è necessario combinare READPAST con altri hint di tabella che richiedono i blocchi, ad esempio UPDLOCK e HOLDLOCK. Se si specifica READPAST sia a livello di riga che a livello di pagina, i blocchi vengono ignorati. È possibile specificare l'argomento READPAST per qualsiasi tabella a cui viene fatto riferimento in un'istruzione UPDATE o DELETE e per qualsiasi tabella a cui viene fatto riferimento in una clausola FROM. Se specificato in un'istruzione UPDATE, l'argomento READPAST viene applicato solo durante la lettura dei dati per l'identificazione dei record da aggiornare, indipendentemente dalla posizione in cui è stato specificato all'intero dell'istruzione. Non è possibile specificare l'argomento READPAST per le tabelle nella clausola INTO di un'istruzione INSERT.Le operazioni di lettura che utilizzano l'argomento READPAST non applicano blocchi. È possibile che le operazioni di aggiornamento o eliminazione che utilizzano l'argomento READPAST applichino blocchi durante la lettura delle chiavi esterne o delle viste indicizzate oppure durante la modifica degli indici secondari.
Si supponga, ad esempio, che la tabella T1 includa un'unica colonna integer con i valori 1, 2, 3, 4 e 5. Se la transazione A modifica il valore 3 impostandolo su 8 ma non è ancora stato eseguito il commit della transazione, un'istruzione SELECT * FROM T1 (READPAST) restituisce i valori 1, 2, 4 e 5. L'argomento READPAST viene principalmente utilizzato per ridurre la contesa dei blocchi durante l'implementazione di una coda di elaborazione che utilizza una tabella SQL Server. Un agente di lettura coda che utilizza l'argomento READPAST ignora le voci della coda bloccate da altre transazioni e passa alla successiva voce disponibile senza attendere il rilascio dei blocchi da parte delle altre transazioni.
READUNCOMMITTED
Indica che le letture dirty sono consentite. Non viene acquisito alcun blocco condiviso per impedire alle altre transazioni di modificare i dati letti dalla transazione corrente. I blocchi esclusivi impostati dalle altre transazioni non impediscono alla transazione corrente di leggere i dati bloccati. Le letture dirty possono provocare un livello più alto di concorrenza a discapito della lettura delle modifiche dei dati per le quali le altre transazioni eseguiranno il rollback. Ciò può determinare la generazione di errori per la transazione oppure la presentazione agli utenti di dati di cui non è stato eseguito il commit.Gli hint READUNCOMMITTED e NOLOCK sono applicabili soltanto a blocchi a livello di dati. Tutte le query, incluse quelle con hint READUNCOMMITTED e NOLOCK, acquisiscono blocchi di stabilità dello schema (Sch-S) durante la compilazione e l'esecuzione. Le query vengono pertanto bloccate in presenza di una transazione simultanea con un blocco di modifica dello schema (Sch-M) sulla tabella. Un'operazione DDL (Data Definition Language), ad esempio, acquisisce un blocco Sch-M prima di modificare le informazioni sullo schema della tabella. Tutte le query simultanee che tentano di acquisire un blocco Sch-S, incluse quelle in esecuzione con hint READUNCOMMITTED o NOLOCK, vengono bloccate. Una query con blocco Sch-S blocca invece le transazioni simultanee che tentano di acquisire un blocco Sch-M. Per ulteriori informazioni sul comportamento di blocco, vedere Compatibilità tra blocchi (Motore di database).
Non è possibile specificare READUNCOMMITTED e NOLOCK per le tabelle modificate da operazioni INSERT, UPDATE o DELETE. Query Optimizer di SQL Server ignora gli hint READUNCOMMITTED e NOLOCK della clausola FROM applicata alla tabella di destinazione di un'istruzione UPDATE o DELETE.
[!NOTA] In una versione futura di Microsoft SQL Server verrà rimosso il supporto per l'utilizzo di hint READUNCOMMITTED e NOLOCK nella clausola FROM per la tabella di destinazione di un'istruzione UPDATE o DELETE. Evitare quindi di utilizzare questi hint in questo contesto nei nuovi progetti di sviluppo e pianificare la modifica delle applicazioni in cui sono attualmente utilizzati.
In SQL Server 2005 è possibile utilizzare le impostazioni seguenti per ridurre al minimo la contesa dei blocchi pur proteggendo le transazioni da letture dirty di modifiche dei dati di cui non è stato eseguito il commit:
- Livello di isolamento READ COMMITTED con l'opzione di database READ_COMMITTED_SNAPSHOT impostata su ON.
- Livello di isolamento SNAPSHOT.
Per ulteriori informazioni sui livelli di isolamento, vedere SET TRANSACTION ISOLATION LEVEL (Transact-SQL).
[!NOTA] Se si verificano errori 601 quando è specificata l'opzione READUNCOMMITTED, risolverli come errori di deadlock (1205), quindi provare a rieseguire l'istruzione.
- REPEATABLEREAD
Specifica che viene eseguita una scansione con la stessa semantica di blocco di una transazione eseguita con un livello di isolamento REPEATABLE READ. Per ulteriori informazioni sui livelli di isolamento, vedere SET TRANSACTION ISOLATION LEVEL (Transact-SQL).
- ROWLOCK
Specifica l'acquisizione dei blocchi di riga quando in genere vengono acquisiti i blocchi di pagina o i blocchi a livello di tabella. Se viene specificato nelle transazioni operative al livello di isolamento SNAPSHOT, i blocchi di riga vengono acquisiti solo se ROWLOCK è combinato con altri hint di tabella che richiedono i blocchi, ad esempio UPDLOCK e HOLDLOCK.
- SERIALIZABLE
Equivale a HOLDLOCK. Rende i blocchi condivisi più restrittivi mantenendoli attivi fino al completamento di una transazione anziché rilasciarli non appena la tabella o la pagina dei dati richiesta non è più necessaria indipendentemente dal completamento della transazione. La scansione viene eseguita con la stessa semantica di una transazione eseguita con il livello di isolamento SERIALIZABLE. Per ulteriori informazioni sui livelli di isolamento, vedere SET TRANSACTION ISOLATION LEVEL (Transact-SQL).
TABLOCK
Specifica l'acquisizione di un blocco sulla tabella, che verrà mantenuto attivo fino al termine dell'istruzione. In caso di lettura dei dati, viene acquisito un blocco condiviso. Per la modifica dei dati viene invece acquisito un blocco esclusivo. Se si specifica anche l'opzione HOLDLOCK, il blocco condiviso a livello di tabella viene mantenuto attivo fino al termine della transazione.Se utilizzato in combinazione con il provider di set di righe con lettura di massa OPENROWSET per importare dati in una tabella senza indici, TABLOCK consente a più client di caricare simultaneamente i dati nella tabella di destinazione ottimizzandone la registrazione e i blocchi.
- TABLOCKX
Specifica l'acquisizione di un blocco esclusivo sulla tabella fino al completamento della transazione.
- UPDLOCK
Specifica che è necessario richiedere i blocchi di aggiornamento, i quali dovranno essere mantenuti attivi fino al completamento della transazione.
- XLOCK
Specifica che è necessario richiedere i blocchi esclusivi, i quali dovranno essere mantenuti attivi fino al completamento della transazione. Se specificato in combinazione con ROWLOCK, PAGLOCK o TABLOCK, i blocchi esclusivi vengono applicati al livello di granularità appropriato.
Osservazioni
Gli hint di tabella vengono ignorati se il piano di query non accede alla tabella. Ciò si verifica se Query Optimizer non accede esplicitamente alla tabella oppure perché viene invece eseguito l'accesso a una vista indicizzata. In questo secondo caso è possibile impedire l'accesso a una vista indicizzata utilizzando l'hint per la query OPTION (EXPAND VIEWS).
È consigliabile utilizzare la virgola per separare gli hint di tabella, anche se ciò non è necessario. La separazione di hint tramite spazi anziché virgole è supportato per compatibilità con le versioni precedenti.
In SQL Server 2005 gli hint di tabella sono supportati nella clausola FROM solo se vengono specificati con la parola chiave WITH con alcune eccezioni. Tali hint devono inoltre essere racchiusi tra parentesi.
Gli hint di tabella riportati di seguito sono supportati sia con che senza la parola chiave WITH: NOLOCK, READUNCOMMITTED, UPDLOCK, REPEATABLEREAD, SERIALIZABLE, READCOMMITTED, FASTFIRSTROW, TABLOCK, TABLOCKX, PAGLOCK, ROWLOCK, NOWAIT, READPAST, XLOCK e NOEXPAND. Se vengono specificati senza la parola chiave WITH, questi hint devono essere specificati da soli. Ad esempio:
FROM t (FASTFIRSTROW)
Se l'hint viene specificato con un'altra opzione, è necessario utilizzare la parola chiave WITH:
FROM t WITH (FASTFIRSTROW, INDEX(myindex))
Le restrizioni sono valide quando gli hint vengono utilizzati nelle query eseguite nei database con livello di compatibilità pari a 90.
In SQL Server 2005 tutti gli hint di blocco vengono distribuiti a tutte le tabelle e viste a cui viene fatto riferimento in una vista. SQL Server esegue inoltre le relative verifiche di consistenza dei blocchi.
È possibile che gli hint di blocco ROWLOCK, UPDLOCK e AND XLOCK che acquisiscono blocchi a livello di riga applichino blocchi alle chiavi di indice anziché alle righe di dati effettive. Se, ad esempio, una tabella include un indice non cluster e un'istruzione SELECT che utilizza un hint di blocco viene gestita da un indice di copertura, viene acquisito un blocco sulla chiave dell'indice di copertura anziché sulla riga di dati nella tabella di base.
Se una tabella include colonne calcolate e le colonne calcolate vengono calcolate in base a espressioni o funzioni che accedono a colonne in altre tabelle, su tali tabelle non verranno utilizzati gli hint di tabella. Ciò significa che gli hint di tabella non vengono propagati. Ad esempio, un hint di tabella NOLOCK è specificato in una tabella della query che include colonne calcolate tramite una combinazione di espressioni e funzioni che accedono alle colonne di un'altra tabella. Le tabelle a cui le espressioni e le funzioni fanno riferimento non utilizzano l'hint di tabella NOLOCK durante l'accesso.
Per ogni tabella nella clausola FROM in SQL Server non è consentito impostare più di un hint di tabella appartenente a ognuno dei gruppi seguenti:
- Hint di granularità: PAGLOCK, NOLOCK, ROWLOCK, TABLOCK o TABLOCKX.
- Hint del livello di isolamento: HOLDLOCK, NOLOCK, READCOMMITTED, REPEATABLEREAD, SERIALIZABLE.
Utilizzo di NOEXPAND
L'hint NOEXPAND è applicabile solo alle viste indicizzate, ovvero alle viste in cui è stato creato un indice cluster univoco. Query Optimizer utilizza l'indice nella vista se una query include riferimenti a colonne disponibili sia in una vista indicizzata che nelle tabelle di base e viene determinato che l'utilizzo della vista indicizzata rappresenta il metodo migliore per l'esecuzione della query. Questa funzione viene definita corrispondenza delle viste indicizzate ed è supportata solo in SQL Server 2005 Enterprise Edition e Developer Edition.
Affinché Query Optimizer utilizzi le viste indicizzate oppure una vista indicizzata a cui viene fatto riferimento tramite l'hint NOEXPAND per l'esecuzione della corrispondenza, le opzioni SET seguenti devono essere impostate su ON:
ANSI_NULLS |
ANSI_WARNINGS |
CONCAT_NULL_YIELDS_NULL |
ANSI_PADDING |
ARITHABORT1 |
QUOTED_IDENTIFIERS |
1 ARITHABORT viene impostata in modo implicito su ON se ANSI_WARNINGS è impostata su ON. Non sarà pertanto necessario modificare manualmente questa impostazione.
L'opzione NUMERIC_ROUNDABORT deve invece essere impostata su OFF.
Per imporre l'utilizzo di un indice per una vista indicizzata in Query Optimizer, è necessario specificare l'opzione NOEXPAND. È possibile utilizzare questo hint solo se nella query è specificata anche la vista. In SQL Server 2005 non è disponibile un hint per imporre l'utilizzo di una vista indicizzata specifica in una query in cui tale vista non viene direttamente specificata nella clausola FROM. Query Optimizer valuterà invece l'utilizzo delle viste indicizzate anche se non sono presenti riferimenti diretti all'interno della query.
Per ulteriori informazioni, vedere Risoluzione di indici nelle viste.
Autorizzazioni
Gli hint KEEPIDENTITY, IGNORE_CONSTRAINTS e IGNORE_TRIGGERS richiedono l'autorizzazione ALTER sulla tabella.
Esempi
Nell'esempio seguente viene impostata l'acquisizione di un blocco condiviso sulla tabella Production.Product
. Tale blocco viene mantenuto attivo fino al termine dell'istruzione UPDATE
.
UPDATE Production.Product
WITH (TABLOCK)
SET ListPrice = ListPrice * 1.10
WHERE ProductNumber LIKE 'BK-%'
Vedere anche
Riferimento
OPENROWSET (Transact-SQL)
Hint (Transact-SQL)
Altre risorse
Hint di blocco
Risoluzione delle viste
Guida in linea e informazioni
Cronologia modifiche
Versione | Cronologia |
---|---|
12 dicembre 2006 |
|
14 aprile 2006 |
|
5 dicembre 2005 |
|