Hint per la query (Transact-SQL)

Si applica a: SQL Server Database SQL di Azure Istanza gestita di SQL di Azure

Gli hint per le query specificano che gli hint indicati vengono usati nell'ambito di una query. e influiscono su tutti gli operatori dell'istruzione. Se UNION è coinvolto nella query principale, solo l'ultima query che include un'operazione UNION può avere la OPTION clausola . Gli hint per la query vengono specificati come parte della clausola OPTION. L'errore 8622 si verifica se in seguito alla presenza di uno o più hint per la query non viene generato un piano valido da Query Optimizer.

Attenzione

Poiché Query Optimizer di SQL Server in genere seleziona il piano di esecuzione ottimale per una query, è consigliabile usare hint solo come ultima risorsa e sempre da parte di sviluppatori e amministratori esperti di database.

Si applica a:

Convenzioni relative alla sintassi Transact-SQL

Sintassi

<query_hint> ::=
{ { HASH | ORDER } GROUP
  | { CONCAT | HASH | MERGE } UNION
  | { LOOP | MERGE | HASH } JOIN
  | DISABLE_OPTIMIZED_PLAN_FORCING
  | EXPAND VIEWS
  | FAST <integer_value>
  | FORCE ORDER
  | { FORCE | DISABLE } EXTERNALPUSHDOWN
  | { FORCE | DISABLE } SCALEOUTEXECUTION
  | IGNORE_NONCLUSTERED_COLUMNSTORE_INDEX
  | KEEP PLAN
  | KEEPFIXED PLAN
  | MAX_GRANT_PERCENT = <numeric_value>
  | MIN_GRANT_PERCENT = <numeric_value>
  | MAXDOP <integer_value>
  | MAXRECURSION <integer_value>
  | NO_PERFORMANCE_SPOOL
  | OPTIMIZE FOR ( @variable_name { UNKNOWN | = <literal_constant> } [ , ...n ] )
  | OPTIMIZE FOR UNKNOWN
  | PARAMETERIZATION { SIMPLE | FORCED }
  | QUERYTRACEON <integer_value>
  | RECOMPILE
  | ROBUST PLAN
  | USE HINT ( <use_hint_name> [ , ...n ] )
  | USE PLAN N'<xml_plan>'
  | TABLE HINT ( <exposed_object_name> [ , <table_hint> [ [ , ] ...n ] ] )
  | FOR TIMESTAMP AS OF '<point_in_time>'
}

<table_hint> ::=
{ NOEXPAND [ , INDEX ( <index_value> [ , ...n ] ) | INDEX = ( <index_value> ) ]
  | INDEX ( <index_value> [ , ...n ] ) | INDEX = ( <index_value> )
  | FORCESEEK [ ( <index_value> ( <index_column_name> [ , ... ] ) ) ]
  | FORCESCAN
  | HOLDLOCK
  | NOLOCK
  | NOWAIT
  | PAGLOCK
  | READCOMMITTED
  | READCOMMITTEDLOCK
  | READPAST
  | READUNCOMMITTED
  | REPEATABLEREAD
  | ROWLOCK
  | SERIALIZABLE
  | SNAPSHOT
  | SPATIAL_WINDOW_MAX_CELLS = <integer_value>
  | TABLOCK
  | TABLOCKX
  | UPDLOCK
  | XLOCK
}

<use_hint_name> ::=
{ 'ASSUME_JOIN_PREDICATE_DEPENDS_ON_FILTERS'
  | 'ASSUME_MIN_SELECTIVITY_FOR_FILTER_ESTIMATES'
  | 'ASSUME_FULL_INDEPENDENCE_FOR_FILTER_ESTIMATES'
  | 'ASSUME_PARTIAL_CORRELATION_FOR_FILTER_ESTIMATES'
  | 'DISABLE_BATCH_MODE_ADAPTIVE_JOINS'
  | 'DISABLE_BATCH_MODE_MEMORY_GRANT_FEEDBACK'
  | 'DISABLE_DEFERRED_COMPILATION_TV'
  | 'DISABLE_INTERLEAVED_EXECUTION_TVF'
  | 'DISABLE_OPTIMIZED_NESTED_LOOP'
  | 'DISABLE_OPTIMIZER_ROWGOAL'
  | 'DISABLE_PARAMETER_SNIFFING'
  | 'DISABLE_ROW_MODE_MEMORY_GRANT_FEEDBACK'
  | 'DISABLE_TSQL_SCALAR_UDF_INLINING'
  | 'DISALLOW_BATCH_MODE'
  | 'ENABLE_HIST_AMENDMENT_FOR_ASC_KEYS'
  | 'ENABLE_QUERY_OPTIMIZER_HOTFIXES'
  | 'FORCE_DEFAULT_CARDINALITY_ESTIMATION'
  | 'FORCE_LEGACY_CARDINALITY_ESTIMATION'
  | 'QUERY_OPTIMIZER_COMPATIBILITY_LEVEL_n'
  | 'QUERY_PLAN_PROFILE'
}

Argomenti

{ HASH | ORDER } GROUP

Specifica che le aggregazioni descritte dalla clausola o DISTINCT della GROUP BY query devono usare l'hashing o l'ordinamento.

{ MERGE | HASH | CONCAT } UNION

Specifica che tutte le UNION operazioni vengono eseguite mediante l'unione, l'hashing o la concatenazione di UNION set. Se viene specificato più UNION hint, Query Optimizer seleziona la strategia meno costosa da tali hint specificati.

{ LOOP | MERGE | HASH } JOIN

Specifica che tutte le operazioni di join vengono eseguite da LOOP JOIN, MERGE JOINo HASH JOIN nell'intera query. Se si specificano più hint di join, Query Optimizer seleziona la strategia di join meno onerosa tra quelle consentite.

Se si specifica un hint di join nella clausola della FROM stessa query per una coppia di tabelle specifica, questo hint di join ha la precedenza nell'unione delle due tabelle. Gli hint per la query devono essere comunque rispettati. L'hint di join per la coppia di tabelle potrebbe limitare solo la selezione dei metodi di join consentiti nell'hint per la query. Per altre informazioni, vedere Hint di join.

DISABLE_OPTIMIZED_PLAN_FORCING

Si applica a: SQL Server, a partire da SQL Server 2022 (16.x)

Disabilita la forzatura del piano ottimizzata per una query.

La forzatura del piano ottimizzato riduce il sovraccarico di compilazione per le query ripetitive imposte. Al completamento della generazione del piano di esecuzione delle query, alcuni specifici passaggi di compilazione vengono archiviati in modo che sia possibile riusarli come script per l'ottimizzazione della riproduzione. Uno script di ottimizzazione della riproduzione viene archiviato come parte del file XML dello showplan compresso in Query Store, in un attributo OptimizationReplay nascosto.

EXPAND VIEWS

Specifica che le viste indicizzate vengono espanse. Specifica anche che Query Optimizer non prende in considerazione alcuna vista indicizzata in sostituzione di qualsiasi parte della query. Una vista viene espansa quando il nome della vista viene sostituito dalla definizione della vista nel testo della query.

Con questo hint per la query viene praticamente disabilitato l'utilizzo diretto di viste indicizzate e di relativi indici nel piano di query.

Nota

La vista indicizzata rimane ridotta se è presente un riferimento diretto alla vista nella parte della SELECT query. La vista rimane condensata anche se si specifica WITH (NOEXPAND) o WITH (NOEXPAND, INDEX( <index_value> [ , *...n* ] ) ). Per altre informazioni sull'hint NOEXPANDper la query, vedere Uso di NOEXPAND.

L'hint influisce solo sulle visualizzazioni nella parte delle SELECT istruzioni, incluse le viste nelle INSERTistruzioni , UPDATEMERGE, e DELETE .

FAST integer_value

Specifica che la query è ottimizzata per il recupero rapido del numero di righe indicato da integer_value. Questo risultato è un numero intero non negativo. Dopo la restituzione del numero di righe indicato dainteger_value, l'esecuzione della query continua e viene generato il set di risultati completo.

FORCE ORDER

Specifica che l'ordine di join indicato dalla sintassi della query viene conservato durante l'ottimizzazione della query. L'uso FORCE ORDER di non influisce sul possibile comportamento di inversione del ruolo di Query Optimizer.

Nota

In un'istruzione MERGE viene eseguito l'accesso alla tabella di origine prima della tabella di destinazione come ordine di join predefinito, a meno che non venga specificata la WHEN SOURCE NOT MATCHED clausola . FORCE ORDER Se si specifica, questo comportamento predefinito viene mantenuto.

{ FORCE | DISABLE } EXTERNALPUSHDOWN

Forzare o disabilitare il pushdown del calcolo delle espressioni di qualificazione in Hadoop. Si applica solo alle query con PolyBase. Non esegue il push nell'archiviazione di Azure.

{ FORCE | DISABLE } SCALEOUTEXECUTION

Forza o disabilita l'esecuzione scale-out delle query PolyBase che usano le tabelle esterne nei cluster Big Data di SQL Server 2019. Questo hint viene applicato solo da una query che usa l'istanza master di un cluster Big Data di SQL. La scalabilità orizzontale si verifica nel pool di calcolo del cluster Big Data.

KEEP PLAN

Modifica le soglie di ricompilazione per le tabelle temporanee e le rende identiche alle soglie per le tabelle permanenti. La soglia di ricompilazione stimata avvia una ricompilazione automatica per la query quando il numero stimato di modifiche alle colonne indicizzate viene apportato a una tabella eseguendo una delle istruzioni seguenti:

  • UPDATE
  • DELETE
  • MERGE
  • INSERT

KEEP PLAN Se si specifica, una query non viene ricompilata spesso quando sono presenti più aggiornamenti di una tabella.

KEEPFIXED PLAN

Impedisce a Query Optimizer di ricompilare una query in seguito a modifiche alle statistiche. KEEPFIXED PLAN Se si specifica, una query viene ricompilazione solo se lo schema delle tabelle sottostanti viene modificato o se sp_recompile viene eseguito su tali tabelle.

IGNORE_NONCLUSTERED_COLUMNSTORE_INDEX

Si applica a: SQL Server, a partire da SQL Server 2012 (11.x).

Impedisce alla query di usare un indice columnstore ottimizzato per la memoria non cluster. Se la query contiene l'hint per la query per evitare l'uso dell'indice columnstore e un hint per l'indice per usare un indice columnstore, gli hint sono in conflitto e la query restituisce un errore.

MAX_GRANT_PERCENT = <numeric_value>

Si applica a: SQL Server, a partire da SQL Server 2012 (11.x) Service Pack 3, SQL Server 2014 (12.x) Service Pack 2 e Database SQL di Azure.

Dimensione massima della concessione di memoria in PERCENT del limite di memoria configurato. È previsto che la query non superi questo limite se la query viene eseguita in un pool di risorse definito dall'utente. In tal caso, se la query non dispone della memoria minima necessaria, il sistema genera un errore. Se una query è in esecuzione nel pool di sistema (impostazione predefinita), ottiene almeno la memoria necessaria per l'esecuzione. Il limite effettivo può essere inferiore se l'impostazione di Resource Governor è inferiore al valore specificato da questo hint. I valori validi sono compresi tra 0,0 e 100,0.

L'hint per la concessione di memoria non è disponibile per la creazione o la ricompilazione dell'indice.

MIN_GRANT_PERCENT = <numeric_value>

Si applica a: SQL Server, a partire da SQL Server 2012 (11.x) Service Pack 3, SQL Server 2014 (12.x) Service Pack 2 e Database SQL di Azure.

Dimensione minima della concessione di memoria in PERCENT del limite di memoria configurato. Nella query è garantito il recupero del valore MAX(required memory, min grant) poiché è necessaria almeno la memoria richiesta per avviare una query. I valori validi sono compresi tra 0,0 e 100,0.

L'opzione di concessione di memoria min_grant_percent sostituisce l'opzione sp_configure (memoria minima per query (KB)) indipendentemente dalle dimensioni. L'hint per la concessione di memoria non è disponibile per la creazione o la ricompilazione dell'indice.

MAXDOP <integer_value>

Si applica a: SQL Server (a partire da SQL Server 2008 (10.0.x)) e Database SQL di Azure.

Esegue l'override dell'opzione di configurazione max degree of parallelism di sp_configure. Esegue l'override anche di Resource Governor per la query che specifica questa opzione. L'hint per la MAXDOP query può superare il valore configurato con sp_configure. Se MAXDOP supera il valore configurato con Resource Governor, il motore di database usa il valore di Resource Governor MAXDOP descritto in ALTER WORKLOAD GROUP. Tutte le regole semantiche usate con l'opzione di configurazione max degree of parallelism sono applicabili quando si usa l'hint per la MAXDOP query. Per altre informazioni, vedere Configurare l'opzione di configurazione del server max degree of parallelism.

Avviso

Se MAXDOP è impostato su zero, il server sceglie il massimo grado di parallelismo.

MAXRECURSION <integer_value>

Specifica il numero massimo di ricorsioni consentito per questa query. number è un numero intero positivo compreso tra 0 e 32.767. Se è specificato 0, non viene applicato alcun limite. Se questa opzione non viene specificata, il limite predefinito per il server è 100.

Quando viene raggiunto il numero specificato o predefinito per MAXRECURSION il limite durante l'esecuzione della query, la query termina e viene restituito un errore.

A causa di questo errore, verrà eseguito il rollback di tutti gli effetti dell'istruzione. Se l'istruzione è un'istruzione SELECT , potrebbero essere restituiti risultati parziali o nessun risultato. È possibile che eventuali risultati parziali non includano tutte le righe nei livelli di ricorsione che superano il livello di ricorsione massimo specificato.

Per altre informazioni, vedere WITH common_table_expression.

NO_PERFORMANCE_SPOOL

Si applica a: SQL Server, a partire da SQL Server 2016 (13.x), e Database SQL di Azure.

Impedisce l'aggiunta di un operatore spool ai piani di query (ad eccezione dei piani in cui spool è necessario per garantire una semantica di aggiornamento valida). In alcuni scenari l'operatore spool può ridurre le prestazioni. Ad esempio, poiché lo spool usa tempdb, potrebbe verificarsi un conflitto per tempdbin presenza di numerose query simultanee in esecuzione con le operazioni di spooling.

OPTIMIZE FOR ( @variable_name { UNKNOWN | = <literal_constant> } [ , ...n ] )

Imposta Query Optimizer in modo che usi un valore specifico per una variabile locale quando la query viene compilata e ottimizzata. Il valore viene utilizzato solo durante l'ottimizzazione della query e non durante l'esecuzione.

  • @variable_name

    Nome di una variabile locale usata in una query, a cui è possibile assegnare un valore da usare con l'hint per la OPTIMIZE FOR query.

  • UNKNOWN

    Specifica che Query Optimizer usa dati statistici anziché il valore iniziale per determinare il valore per una variabile locale durante l'ottimizzazione della query.

  • literal_constant

    Valore costante letterale da assegnare @variable_name da usare con l'hint per la OPTIMIZE FOR query. literal_constant si usa solo durante l'ottimizzazione della query e non come valore di @variable_name durante l'esecuzione della query. literal_constant può essere di qualsiasi tipo di dati di sistema di SQL Server esprimibile come costante letterale. Il tipo di dati di literal_constant deve supportare la conversione implicita nel tipo di dati a cui @variable_name fa riferimento nella query.

OPTIMIZE FOR può neutralizzare il comportamento predefinito di rilevamento dei parametri di Query Optimizer. Usare OPTIMIZE FOR anche quando si creano guide di piano. Per altre informazioni, vedere Ricompilare una stored procedure.

OPTIMIZE FOR UNKNOWN

Indica a Query Optimizer di usare la selettività media del predicato in tutti i valori di colonna, anziché usare il valore del parametro di runtime quando la query viene compilata e ottimizzata.

Se si usano OPTIMIZE FOR @variable_name = <literal_constant> e OPTIMIZE FOR UNKNOWN nello stesso hint per la query, Query Optimizer utilizza il valore di literal_constant indicato per un valore specifico. Query Optimizer utilizza UNKNOWN per i restanti valori di variabile. I valori vengono utilizzati durante l'ottimizzazione della query e non durante l'esecuzione di questa.

PARAMETERIZATION { SIMPLE | FORCED }

Specifica le regole di parametrizzazione che Query Optimizer di SQL Server applica alla query durante la compilazione.

Importante

L'hint PARAMETERIZATION per la query può essere specificato solo all'interno di una guida di piano per eseguire l'override dell'impostazione corrente dell'opzione PARAMETERIZATION di database SET . e non direttamente all'interno di una query.

Per altre informazioni, vedere Specificare il comportamento di parametrizzazione delle query tramite guide di piano.

SIMPLE indica a Query Optimizer di tentare la parametrizzazione semplice. FORCED indica a Query Optimizer di tentare la parametrizzazione forzata. Per altre informazioni, vedere Parametrizzazione forzata in Guida sull'architettura di elaborazione delle query, e Parametrizzazione semplice in Guida sull'architettura di elaborazione delle query.

QUERYTRACEON <integer_value>

Questa opzione consente di abilitare un flag di traccia che influisce sul piano solo durante la compilazione di una singola query. Analogamente ad altre opzioni a livello di query, è possibile usarla insieme alle guide di piano per trovare il testo corrispondente di una query eseguita da qualsiasi sessione e applicare automaticamente un flag di traccia che influisce sul piano quando la query viene compilata. L'opzione QUERYTRACEON è supportata solo per i flag di traccia di Query Optimizer. Per altre informazioni, vedere Flag di traccia.

L'uso di questa opzione non restituisce alcun errore o avviso se viene usato un numero di flag di traccia non supportato. Se il flag di traccia specificato non influisce su un piano di esecuzione di query, l'opzione viene ignorata automaticamente.

Per usare più flag di traccia in una query, specificare un QUERYTRACEON hint per ogni numero di flag di traccia diverso.

RECOMPILE

Indica al motore di database di SQL Server di generare un nuovo piano temporaneo per la query e di eliminarlo immediatamente al termine dell'esecuzione della query. Il piano di query generato non sostituisce un piano archiviato nella cache quando la stessa query viene eseguita senza l'hint RECOMPILE . Senza specificare RECOMPILE, il motore di database memorizza nella cache i piani di query e li riutilizza. Quando i piani di query vengono compilati, l'hint per la RECOMPILE query usa i valori correnti di qualsiasi variabile locale nella query. Se la query è contenuta in una stored procedure, vengono usati i valori correnti passati ai parametri.

RECOMPILE è un'alternativa utile alla creazione di una stored procedure. RECOMPILE utilizza la WITH RECOMPILE clausola quando è necessario ricompilare solo un subset di query all'interno della stored procedure anziché l'intera stored procedure. Per altre informazioni, vedere Ricompilare una stored procedure. RECOMPILE è utile anche quando si creano guide di piano.

ROBUST PLAN

Impone in Query Optimizer l'applicazione di un piano che funziona anche con dimensioni di riga massime, eventualmente a scapito delle prestazioni. Quando la query viene elaborata, è possibile che tabelle e operatori intermedi debbano archiviare ed elaborare righe con dimensioni maggiori rispetto a qualsiasi riga di input. Talvolta le righe possono essere talmente estese che l'operatore specifico non è in grado di elaborarle. In questi casi, il motore di database genera un errore durante l'esecuzione della query. Usando ROBUST PLAN, si indica a Query Optimizer di non considerare i piani di query che potrebbero verificarsi in questo problema.

Se non è possibile implementare tale piano, Query Optimizer restituisce un errore invece di posticipare il rilevamento degli errori fino all'esecuzione della query. Le righe possono includere colonne di lunghezza variabile. Il motore di database consente di definire righe con dimensioni potenziali massime superiori alla sua capacità di elaborazione. In generale, nonostante le dimensioni potenziali massime, nelle applicazioni vengono archiviate righe con dimensioni effettive comprese nei limiti della capacità di elaborazione del motore di database. Se il motore di database rileva una riga di lunghezza eccessiva, viene restituito un errore di esecuzione.

USE HINT ( 'hint_name' )

Si applica a: SQL Server, a partire da SQL Server 2016 (13.x) SP1, e Database SQL di Azure.

Fornisce uno o più hint aggiuntivi per Query Processor. Gli hint aggiuntivi vengono specificati con un nome di hint all'interno di virgolette singole.

Suggerimento

Per i nomi degli hint non viene fatta distinzione tra maiuscole e minuscole.

Sono supportati i nomi di hint seguenti:

Alludere Descrizione
'ASSUME_JOIN_PREDICATE_DEPENDS_ON_FILTERS' Fa sì che SQL Server generi un piano di query usando il presupposto di contenimento semplice anziché il presupposto di contenimento di base predefinito per i join, nel modello di stima della cardinalità di Query Optimizer di SQL Server 2014 (12.x) e versioni successive. Questo nome di hint equivale al flag di traccia 9476.
'ASSUME_MIN_SELECTIVITY_FOR_FILTER_ESTIMATES' Fa in modo che SQL Server generi un piano che usa la selettività minima durante la stima dei predicati AND per i filtri per tenere conto della correlazione completa. Questo nome di hint equivale al flag di traccia 4137 quando viene usato con il modello di stima della cardinalità di SQL Server 2012 (11.x) e versioni precedenti e ha un effetto simile quando viene usato il flag di traccia 9471 con il modello di stima della cardinalità di SQL Server 2014 (12.x) e versioni successive.
'ASSUME_FULL_INDEPENDENCE_FOR_FILTER_ESTIMATES' Fa in modo che SQL Server generi un piano che usa la selettività massima durante la stima dei predicati AND per i filtri per tenere conto dell'indipendenza completa. Questo nome di hint è il comportamento predefinito del modello di stima della cardinalità di SQL Server 2012 (11.x) e versioni precedenti ed equivalente al flag di traccia 9472 quando viene usato con il modello di stima della cardinalità di SQL Server 2014 (12.x) e versioni successive.

Si applica a: Database SQL di Azure
'ASSUME_PARTIAL_CORRELATION_FOR_FILTER_ESTIMATES' Fa in modo che SQL Server generi un piano che usa la maggior parte della selettività minima durante la stima dei predicati AND per i filtri per tenere conto della correlazione parziale. Questo nome di hint è il comportamento predefinito del modello di stima della cardinalità di SQL Server 2014 (12.x) e versioni successive.

Si applica a: Database SQL di Azure
'DISABLE_BATCH_MODE_ADAPTIVE_JOINS' Disabilita i join adattivi in modalità batch. Per altre informazioni, vedere Join adattivi in modalità batch.

Si applica a: SQL Server 2017 (14.x) e versioni successive e database SQL di Azure
'DISABLE_BATCH_MODE_MEMORY_GRANT_FEEDBACK' Disabilita il feedback delle concessioni di memoria in modalità batch. Per altre informazioni, vedere Feedback delle concessioni di memoria in modalità batch.

Si applica a: SQL Server 2017 (14.x) e versioni successive e database SQL di Azure
'DISABLE_DEFERRED_COMPILATION_TV' Disabilita la compilazione posticipata delle variabili di tabella. Per altre informazioni, vedere Compilazione posticipata delle variabili di tabella.

Si applica a: SQL Server 2019 (15.x) e versioni successive e database SQL di Azure
'DISABLE_INTERLEAVED_EXECUTION_TVF' Disabilita l'esecuzione interleaved per funzioni con valori di tabella a più istruzioni. Per altre informazioni, vedere Esecuzione interleaved per funzioni con valori di tabella a più istruzioni.

Si applica a: SQL Server 2017 (14.x) e versioni successive e database SQL di Azure
'DISABLE_OPTIMIZED_NESTED_LOOP' Indica a Query Processor di non usare un'operazione di ordinamento (ordinamento batch) per i join a cicli annidati ottimizzati durante la generazione di un piano. Questo nome di hint equivale al flag di traccia 2340. Questo hint si applica anche agli ordinamenti espliciti e ai batch.
'DISABLE_OPTIMIZER_ROWGOAL' Fa in modo che SQL Server generi un piano che non usa le rettifiche degli obiettivi di riga con query contenenti queste parole chiave:

- TOP
- OPTION (FAST N)
- IN
- EXISTS

Questo nome di hint equivale al flag di traccia 4138.
'DISABLE_PARAMETER_SNIFFING' Indica a Query Optimizer di usare una distribuzione dei dati media durante la compilazione di una query con uno o più parametri. Questa istruzione rende il piano di query indipendente dal valore del parametro usato inizialmente durante la compilazione della query. Questo nome di hint equivale all'impostazione PARAMETER_SNIFFING = OFFdi configurazione con ambito database 4136 o flag di traccia.
'DISABLE_ROW_MODE_MEMORY_GRANT_FEEDBACK' Disabilita il feedback delle concessioni di memoria in modalità riga. Per altre informazioni, vedere Feedback delle concessioni di memoria in modalità riga.

Si applica a: SQL Server 2019 (15.x) e versioni successive e database SQL di Azure
'DISABLE_TSQL_SCALAR_UDF_INLINING' Abilita l'inlining di funzioni scalari definite dall'utente. Per altre informazioni, vedere Inlining di funzioni definite dall'utente scalari.

Si applica a: SQL Server 2019 (15.x) e versioni successive e database SQL di Azure
'DISALLOW_BATCH_MODE' Disabilita l'esecuzione in modalità batch. Per altre informazioni, vedere Modalità di esecuzione.

Si applica a: SQL Server 2019 (15.x) e versioni successive e database SQL di Azure
'ENABLE_HIST_AMENDMENT_FOR_ASC_KEYS' Abilita le statistiche rapide generate automaticamente (modifica istogramma) per qualsiasi colonna di indice iniziale per cui è necessaria la stima della cardinalità. L'istogramma usato per stimare la cardinalità viene regolato in fase di compilazione della query per tenere conto del valore massimo o minimo effettivo di questa colonna. Questo nome di hint equivale al flag di traccia 4139.
'ENABLE_QUERY_OPTIMIZER_HOTFIXES' Abilita gli hotfix di Query Optimizer (modifiche rilasciate negli aggiornamenti cumulativi e nei Service Pack di SQL Server). Questo nome di hint equivale all'impostazione QUERY_OPTIMIZER_HOTFIXES = ONdi configurazione con ambito database o flag di traccia 4199.
'FORCE_DEFAULT_CARDINALITY_ESTIMATION' Forza in Query Optimizer l'utilizzo del modello di stima della cardinalità che corrisponde al livello di compatibilità del database corrente. Usare questo hint per eseguire l'override dell'impostazione LEGACY_CARDINALITY_ESTIMATION = ON di configurazione con ambito database o flag di traccia 9481.
'FORCE_LEGACY_CARDINALITY_ESTIMATION' Forza Query Optimizer a usare il modello di stima della cardinalità di SQL Server 2012 (11.x) e versioni precedenti. Questo nome di hint equivale all'impostazione LEGACY_CARDINALITY_ESTIMATION = ONdi configurazione con ambito database 9481 o flag di traccia.
'QUERY_OPTIMIZER_COMPATIBILITY_LEVEL_n' 1 Forza il comportamento di Query Optimizer a livello di query. Il comportamento rispecchia quello che si verifica se la query viene compilata con il livello di compatibilità del database n, dove n è un livello di compatibilità del database supportato. Per un elenco dei valori attualmente supportati per n, vedere sys.dm_exec_valid_use_hints.

Si applica a: SQL Server 2017 (14.x) CU 10 e versioni successive e database SQL di Azure
'QUERY_PLAN_PROFILE' 2 Abilita la profilatura leggera per la query. Al termine di una query contenente questo nuovo hint, viene generato un nuovo evento esteso, query_plan_profile, . Questo evento esteso espone le statistiche di esecuzione e il codice XML effettivo del piano di esecuzione simile all'evento query_post_execution_showplan esteso, ma solo per le query che contengono il nuovo hint.

Si applica a: SQL Server 2016 (13.x) SP 2 CU 3, SQL Server 2017 (14.x) CU 11 e versioni successive

1 L'hint non esegue l'override QUERY_OPTIMIZER_COMPATIBILITY_LEVEL_n dell'impostazione di stima della cardinalità predefinita o legacy, se viene forzata tramite la configurazione con ambito database, il flag di traccia o un altro hint per la query, ad QUERYTRACEONesempio . Questo hint influisce solo sul comportamento di Query Optimizer. Non ha effetto su altre funzionalità di SQL Server che possono dipendere dal livello di compatibilità del database, ad esempio la disponibilità di determinate funzionalità di database. Per altre informazioni, vedere Developer's Choice: Hinting Query Execution model .For more information, see Developer's Choice: Hinting Query Execution model.

2 Se si abilita la raccolta dell'evento esteso, l'infrastruttura query_post_execution_showplan di profilatura standard viene aggiunta a ogni query in esecuzione nel server e pertanto può influire sulle prestazioni complessive del server. Se si abilita la raccolta di eventi estesi per l'uso dell'infrastruttura query_thread_profile di profilatura leggera, ciò comporta un sovraccarico di prestazioni molto inferiore, ma influisce comunque sulle prestazioni complessive del server. Se si abilita l'evento esteso, questo abilita solo l'infrastruttura query_plan_profile di profilatura leggera per una query eseguita con query_plan_profile e pertanto non influisce su altri carichi di lavoro nel server. Usare questo hint per profilare una query specifica senza effetti sulle altre parti del carico di lavoro del server. Per altre informazioni sulla profilatura leggera, vedere Infrastruttura di profilatura query.

È possibile eseguire query sull'elenco di tutti i nomi supportati USE HINT usando la visualizzazione a gestione dinamica sys.dm_exec_valid_use_hints.

Importante

Alcuni USE HINT hint potrebbero essere in conflitto con i flag di traccia abilitati a livello globale o di sessione o con impostazioni di configurazione con ambito database. In questo caso, l'hint a livello di query (USE HINT) ha sempre la precedenza. Se un USE HINT oggetto è in conflitto con un altro hint per la query o un flag di traccia abilitato a livello di query ,ad esempio QUERYTRACEON, SQL Server genererà un errore quando si tenta di eseguire la query.

USE PLAN N'xml_plan'

Forza Query Optimizer a usare un piano di query esistente per una query specificata da xml_plan. USE PLANnon può essere specificato con INSERTistruzioni , UPDATEMERGE, o DELETE .

Il piano di esecuzione risultante forzato da questa funzionalità è lo stesso o simile al piano forzato. Poiché il piano risultante potrebbe non essere identico al piano specificato da USE PLAN, le prestazioni dei piani possono variare. In rari casi, la differenza di prestazioni può essere significativa e negativa; in tal caso, l'amministratore deve rimuovere il piano forzato.

TABLE HINT ( exposed_object_name [ , <table_hint> [ [ , ] ... n ] ] )

Applica l'hint di tabella specificato alla tabella o alla vista che corrisponde a exposed_object_name. È consigliabile usare un hint di tabella come hint per la query solo nel contesto di una guida di piano.

exposed_object_name può essere uno dei riferimenti seguenti:

  • Quando viene usato un alias per la tabella o la visualizzazione nella clausola FROM della query, exposed_object_name è l'alias.

  • Quando non viene usato un alias, exposed_object_name corrisponde esattamente alla tabella o alla vista a cui viene fatto riferimento nella FROM clausola . Ad esempio, se viene fatto riferimento alla tabella o alla visualizzazione usando un nome in due parti, exposed_object_name è lo stesso nome in due parti.

Quando si specificaexposed_object_name senza specificare anche un hint di tabella, gli indici specificati nella query come parte di un hint di tabella per l'oggetto non vengono considerati. Query Optimizer determina quindi l'utilizzo degli indici. È possibile usare questa tecnica per eliminare l'effetto di un INDEX hint di tabella quando non è possibile modificare la query originale. Vedere Esempio di J.

<table_hint>

NOEXPAND [ , INDEX ( index_value [ ,... n ] ) | INDEX = ( index_value ) ] | INDEX ( index_value [ ,... n ] ) | INDEX = ( index_value ) | FORCESEEK [ ( index_value ( index_column_name [,... ] ) ) ] | FORCESCAN | HOLDLOCK | NOLOCK | NOWAIT | PAGLOCK | READCOMMITTED | READCOMMITTEDLOCK | READPAST | READUNCOMMITTED | REPEATABLEREAD | ROWLOCK | SERIALIZABLE | SNAPSHOT | SPATIAL_WINDOW_MAX_CELLS = integer_value | TABLOCK | TABLOCKX | UPDLOCK | XLOCK

Hint di tabella da applicare alla tabella o alla vista che corrisponde a exposed_object_name come hint per la query. Per una descrizione di questi hint, vedere Hint di tabella.

Gli hint di tabella diversi da INDEX, FORCESCANe FORCESEEK non sono consentiti come hint per la query, a meno che la query non abbia già una WITH clausola che specifica l'hint per la tabella. Per altre informazioni, vedere la sezione Osservazioni.

Attenzione

FORCESEEK Se si specifica con parametri, il numero di piani che è possibile considerare da Query Optimizer è maggiore di quando si specifica FORCESEEK senza parametri. In questo caso potrebbe essere generato un errore "Impossibile generare il piano" con maggiore frequenza.

PER DATA E ORA COME IN 'point_in_time'

Si applica a: magazzino in Microsoft Fabric

Usare la sintassi TIMESTAMP nella formula OPTION per eseguire query sui dati esistenti in passato, parte della funzionalità di spostamento temporale in Synapse Data Warehouse in Microsoft Fabric.

Specificare il point_in_time nel formato yyyy-MM-ddTHH:mm:ss[.fff] per restituire i dati così come sono apparsi in quel momento. Il fuso orario è sempre in formato UTC. Usare la sintassi CONVERT per il formato datetime necessario con stile 126.

L'hint TIMESTAMP AS OF può essere specificato una sola volta usando la formula OPTION. Per altre informazioni e limitazioni, si veda Eseguire query sui dati esistenti in passato.

Osservazioni:

Gli hint per la query non possono essere specificati in un'istruzione INSERT , tranne quando viene usata una SELECT clausola all'interno dell'istruzione .

È possibile specificare gli hint per la query solo nella query di livello principale e non nelle sottoquery. Quando un hint di tabella viene specificato come hint per la query, l'hint può essere specificato nella query di livello superiore o in una sottoquery. Tuttavia, il valore specificato per exposed_object_name nella TABLE HINT clausola deve corrispondere esattamente al nome esposto nella query o nella sottoquery.

Specificare hint di tabella come hint per la query

È consigliabile usare l'hint INDEXdi tabella , FORCESCANo FORCESEEK come hint per la query solo nel contesto di una guida di piano. Le guide di piano sono utili quando non è possibile modificare la query originale, ad esempio perché si tratta di un'applicazione di terze parti. L'hint per la query specificato nella guida di piano viene aggiunto alla query prima della compilazione e ottimizzato. Per le query ad hoc, usare la TABLE HINT clausola solo quando si testano le istruzioni della guida di piano. Per tutte le altre query ad hoc, è consigliabile specificare tali hint solo come hint di tabella.

Se specificato come hint per la query, gli INDEXhint di tabella , FORCESCANe FORCESEEK sono validi per gli oggetti seguenti:

  • Tabelle
  • Visualizzazioni
  • Viste indicizzate
  • Espressioni di tabella comuni (l'hint deve essere specificato nell'istruzione il SELECT cui set di risultati popola l'espressione di tabella comune)
  • Viste a gestione dinamica (DMV)
  • Sottoquery denominate

È possibile specificare INDEXhint di tabella , FORCESCANe FORCESEEK come hint di query per una query che non dispone di hint di tabella esistenti. È anche possibile usarli per sostituire rispettivamente gli hint , FORCESCANo FORCESEEK esistenti INDEXnella query.

Gli hint di tabella diversi da INDEX, FORCESCANe FORCESEEK non sono consentiti come hint per la query, a meno che la query non abbia già una WITH clausola che specifica l'hint per la tabella. In questo caso, è necessario specificare anche un hint corrispondente come hint per la query. Specificare l'hint corrispondente come hint per la query usando TABLE HINT nella OPTION clausola . In questo modo, è possibile mantenere la semantica della query. Ad esempio, se la query contiene l'hint NOLOCKdi tabella , la OPTION clausola nel parametro @hints della guida di piano deve contenere anche l'hint NOLOCK . Vedere l'esempio K.

Specificare gli hint con hint di Query Store

È possibile imporre hint sulle query identificate tramite Query Store senza apportare modifiche al codice usando la funzionalità degli hint di Query Store. Usare la stored procedure sys.sp_query_store_set_hints per applicare un hint a una query. Vedere l'esempio N.

Esempi

R. Usare MERGE JOIN

Nell'esempio seguente viene specificata l'esecuzione MERGE JOIN dell'operazione JOIN nella query. Nell'esempio viene utilizzato il database AdventureWorks2022.

SELECT *
FROM Sales.Customer AS c
INNER JOIN Sales.CustomerAddress AS ca ON c.CustomerID = ca.CustomerID
WHERE TerritoryID = 5
OPTION (MERGE JOIN);
GO

B. Usare OPTIMIZE FOR

Nell'esempio seguente si indica a Query Optimizer di usare il valore 'Seattle' per @city_name e di applicare la selettività media del predicato a tutti i valori di colonna per @postal_code durante l'ottimizzazione della query. Nell'esempio viene utilizzato il database AdventureWorks2022.

CREATE PROCEDURE dbo.RetrievePersonAddress
@city_name NVARCHAR(30),
@postal_code NVARCHAR(15)
AS
SELECT * FROM Person.Address
WHERE City = @city_name AND PostalCode = @postal_code
OPTION ( OPTIMIZE FOR (@city_name = 'Seattle', @postal_code UNKNOWN) );
GO

C. Usare MAXRECURSION

MAXRECURSION può essere usato per impedire che un'espressione di tabella comune ricorsiva non corretta venga immessa in un ciclo infinito. Nell'esempio seguente viene creato intenzionalmente un ciclo infinito e viene utilizzato l'hint MAXRECURSION per limitare a due il numero di livelli di ricorsione. Nell'esempio viene utilizzato il database AdventureWorks2022.

--Creates an infinite loop
WITH cte (CustomerID, PersonID, StoreID) AS
(
    SELECT CustomerID, PersonID, StoreID
    FROM Sales.Customer
    WHERE PersonID IS NOT NULL
  UNION ALL
    SELECT cte.CustomerID, cte.PersonID, cte.StoreID
    FROM cte
    JOIN  Sales.Customer AS e
        ON cte.PersonID = e.CustomerID
)
--Uses MAXRECURSION to limit the recursive levels to 2
SELECT CustomerID, PersonID, StoreID
FROM cte
OPTION (MAXRECURSION 2);
GO

Dopo la correzione dell'errore di codifica, MAXRECURSION non è più necessario.

D. Usare MERGE UNION

Nell'esempio seguente viene utilizzato l'hint per la query MERGE UNION. Nell'esempio viene utilizzato il database AdventureWorks2022.

SELECT *
FROM HumanResources.Employee AS e1
UNION
SELECT *
FROM HumanResources.Employee AS e2
OPTION (MERGE UNION);
GO

E. Usare HASH GROUP e FAST

Nell'esempio seguente vengono usati gli hint per la HASH GROUP query e FAST . Nell'esempio viene utilizzato il database AdventureWorks2022.

SELECT ProductID, OrderQty, SUM(LineTotal) AS Total
FROM Sales.SalesOrderDetail
WHERE UnitPrice < $5.00
GROUP BY ProductID, OrderQty
ORDER BY ProductID, OrderQty
OPTION (HASH GROUP, FAST 10);
GO

F. Usare MAXDOP

Nell'esempio seguente viene utilizzato l'hint per la query MAXDOP. Nell'esempio viene utilizzato il database AdventureWorks2022.

SELECT ProductID, OrderQty, SUM(LineTotal) AS Total
FROM Sales.SalesOrderDetail
WHERE UnitPrice < $5.00
GROUP BY ProductID, OrderQty
ORDER BY ProductID, OrderQty
OPTION (MAXDOP 2);
GO

G. Usare INDEX

Negli esempi seguenti viene usato l'hint INDEX . Nel primo esempio viene specificato un singolo indice. Nel secondo esempio vengono specificati più indici per un singolo riferimento alla tabella. In entrambi gli esempi, poiché si applica l'hint INDEX in una tabella che usa un alias, la TABLE HINT clausola deve specificare anche lo stesso alias del nome dell'oggetto esposto. Nell'esempio viene utilizzato il database AdventureWorks2022.

EXEC sp_create_plan_guide
    @name = N'Guide1',
    @stmt = N'SELECT c.LastName, c.FirstName, e.Title
              FROM HumanResources.Employee AS e
              JOIN Person.Contact AS c ON e.ContactID = c.ContactID
              WHERE e.ManagerID = 2;',
    @type = N'SQL',
    @module_or_batch = NULL,
    @params = NULL,
    @hints = N'OPTION (TABLE HINT(e, INDEX (IX_Employee_ManagerID)))';
GO
EXEC sp_create_plan_guide
    @name = N'Guide2',
    @stmt = N'SELECT c.LastName, c.FirstName, e.Title
              FROM HumanResources.Employee AS e
              JOIN Person.Contact AS c ON e.ContactID = c.ContactID
              WHERE e.ManagerID = 2;',
    @type = N'SQL',
    @module_or_batch = NULL,
    @params = NULL,
    @hints = N'OPTION (TABLE HINT(e, INDEX(PK_Employee_EmployeeID, IX_Employee_ManagerID)))';
GO

H. Usare FORCESEEK

Nell'esempio seguente viene usato l'hint per la FORCESEEK tabella. La TABLE HINT clausola deve inoltre specificare lo stesso nome in due parti del nome dell'oggetto esposto. Specificare il nome quando si applica l'hint INDEX in una tabella che usa un nome in due parti. Nell'esempio viene utilizzato il database AdventureWorks2022.

EXEC sp_create_plan_guide
    @name = N'Guide3',
    @stmt = N'SELECT c.LastName, c.FirstName, HumanResources.Employee.Title
              FROM HumanResources.Employee
              JOIN Person.Contact AS c ON HumanResources.Employee.ContactID = c.ContactID
              WHERE HumanResources.Employee.ManagerID = 3
              ORDER BY c.LastName, c.FirstName;',
    @type = N'SQL',
    @module_or_batch = NULL,
    @params = NULL,
    @hints = N'OPTION (TABLE HINT( HumanResources.Employee, FORCESEEK))';
GO

I. Usare più hint di tabella

Nell'esempio seguente viene applicato l'hint INDEX a una tabella e all'hint FORCESEEK a un altro. Nell'esempio viene utilizzato il database AdventureWorks2022.

EXEC sp_create_plan_guide
    @name = N'Guide4',
    @stmt = N'SELECT e.ManagerID, c.LastName, c.FirstName, e.Title
              FROM HumanResources.Employee AS e
              JOIN Person.Contact AS c ON e.ContactID = c.ContactID
              WHERE e.ManagerID = 3;',
    @type = N'SQL',
    @module_or_batch = NULL,
    @params = NULL,
    @hints = N'OPTION (TABLE HINT (e, INDEX( IX_Employee_ManagerID))
                       , TABLE HINT (c, FORCESEEK))';
GO

J. Usare TABLE HINT per eseguire l'override di un hint di tabella esistente

Nell'esempio seguente viene illustrato come usare l'hint TABLE HINT . È possibile usare l'hint senza specificare un hint per eseguire l'override del INDEX comportamento dell'hint FROM di tabella specificato nella clausola della query. Nell'esempio viene utilizzato il database AdventureWorks2022.

EXEC sp_create_plan_guide
    @name = N'Guide5',
    @stmt = N'SELECT e.ManagerID, c.LastName, c.FirstName, e.Title
              FROM HumanResources.Employee AS e WITH (INDEX (IX_Employee_ManagerID))
              JOIN Person.Contact AS c ON e.ContactID = c.ContactID
              WHERE e.ManagerID = 3;',
    @type = N'SQL',
    @module_or_batch = NULL,
    @params = NULL,
    @hints = N'OPTION (TABLE HINT(e))';
GO

K. Specificare hint di tabella che influiscono sulla semantica

L'esempio seguente contiene due hint di tabella nella query: NOLOCK, che influisce sulla semantica e INDEX, che non influisce sulla semantica. Per mantenere la semantica della query, l'hint NOLOCK viene specificato nella OPTIONS clausola della guida di piano. Insieme all'hint NOLOCK , specificare gli INDEX hint e FORCESEEK e sostituire l'hint che non influisce sulla INDEX semantica nella query durante la compilazione e l'ottimizzazione delle istruzioni. Nell'esempio viene utilizzato il database AdventureWorks2022.

EXEC sp_create_plan_guide
    @name = N'Guide6',
    @stmt = N'SELECT c.LastName, c.FirstName, e.Title
              FROM HumanResources.Employee AS e
                   WITH (NOLOCK, INDEX (PK_Employee_EmployeeID))
              JOIN Person.Contact AS c ON e.ContactID = c.ContactID
              WHERE e.ManagerID = 3;',
    @type = N'SQL',
    @module_or_batch = NULL,
    @params = NULL,
    @hints = N'OPTION (TABLE HINT (e, INDEX(IX_Employee_ManagerID), NOLOCK, FORCESEEK))';
GO

Nell'esempio seguente viene illustrato un metodo alternativo per mantenere la semantica della query e consentire a Query Optimizer di scegliere un indice diverso da quello specificato nell'hint di tabella. Consentire a Optimizer di scegliere specificando l'hint NOLOCK nella OPTIONS clausola . Si specifica l'hint perché influisce sulla semantica. Specificare quindi la TABLE HINT parola chiave con solo un riferimento a una tabella e nessun INDEX hint. Nell'esempio viene utilizzato il database AdventureWorks2022.

EXEC sp_create_plan_guide
    @name = N'Guide7',
    @stmt = N'SELECT c.LastName, c.FirstName, e.Title
              FROM HumanResources.Employee AS e
                   WITH (NOLOCK, INDEX (PK_Employee_EmployeeID))
              JOIN Person.Contact AS c ON e.ContactID = c.ContactID
              WHERE e.ManagerID = 2;',
    @type = N'SQL',
    @module_or_batch = NULL,
    @params = NULL,
    @hints = N'OPTION (TABLE HINT (e, NOLOCK))';
GO

.L Usare USE HINT

Nell'esempio seguente vengono usati gli hint per la RECOMPILE query e USE HINT . Nell'esempio viene utilizzato il database AdventureWorks2022.

SELECT * FROM Person.Address
WHERE City = 'SEATTLE' AND PostalCode = 98104
OPTION (RECOMPILE, USE HINT ('ASSUME_MIN_SELECTIVITY_FOR_FILTER_ESTIMATES', 'DISABLE_PARAMETER_SNIFFING'));
GO

M. Usare QUERYTRACEON HINT

Nell'esempio seguente vengono usati gli hint per la QUERYTRACEON query. Nell'esempio viene utilizzato il database AdventureWorks2022. È possibile abilitare tutti gli hotfix per i piani controllati dal flag di traccia 4199 per una determinata query usando la query seguente:

SELECT * FROM Person.Address
WHERE City = 'SEATTLE' AND PostalCode = 98104
OPTION (QUERYTRACEON 4199);

È anche possibile usare più flag di traccia come nella query seguente:

SELECT * FROM Person.Address
WHERE City = 'SEATTLE' AND PostalCode = 98104
OPTION  (QUERYTRACEON 4199, QUERYTRACEON 4137);

N. Usare gli hint di Query Store

La funzionalità degli hint di Query Store in Database SQL di Azure offre un metodo semplice per modellare i piani di query senza cambiare il codice dell'applicazione.

Prima di tutto, identificare la query già eseguita nelle viste del catalogo di Query Store, ad esempio:

SELECT q.query_id, qt.query_sql_text
FROM sys.query_store_query_text qt
INNER JOIN sys.query_store_query q ON
    qt.query_text_id = q.query_text_id
WHERE query_sql_text like N'%ORDER BY ListingPrice DESC%'
  AND query_sql_text not like N'%query_store%';
GO

Nell'esempio seguente viene applicato l'hint per forzare lo strumento di stima della cardinalità legacy a query_id 39, identificata in Query Store:

EXEC sys.sp_query_store_set_hints @query_id= 39, @query_hints = N'OPTION(USE HINT(''FORCE_LEGACY_CARDINALITY_ESTIMATION''))';

L'esempio seguente applica l'hint per applicare una dimensione massima di concessione di memoria in PERCENT del limite di memoria configurato a query_id 39, identificato in Query Store:

EXEC sys.sp_query_store_set_hints @query_id= 39, @query_hints = N'OPTION(MAX_GRANT_PERCENT=10)';

L'esempio seguente applica più hint di query a query_id 39, tra cui RECOMPILE, MAXDOP 1e il comportamento di Query Optimizer di SQL Server 2012 (11.x):

EXEC sys.sp_query_store_set_hints @query_id= 39,
    @query_hints = N'OPTION(RECOMPILE, MAXDOP 1, USE HINT(''QUERY_OPTIMIZER_COMPATIBILITY_LEVEL_110''))';

.O Eseguire query sui dati a partire da un punto nel tempo

Si applica a: magazzino in Microsoft Fabric

Usare la sintassi TIMESTAMP nella formula OPTION per eseguire query sui dati esistenti in passato, in Synapse Data Warehouse in Microsoft Fabric. La seguente query di esempio restituisce i dati visualizzati il 13 marzo 2024 alle 7:39:35.28 UTC. Il fuso orario è sempre in formato UTC.

SELECT OrderDateKey, SUM(SalesAmount) AS TotalSales
FROM FactInternetSales
GROUP BY OrderDateKey
ORDER BY OrderDateKey
OPTION (FOR TIMESTAMP AS OF '2024-03-13T19:39:35.28');--March 13, 2024 at 7:39:35.28 PM UTC