Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
Aurora Il mio thread afferma SQL
Di seguito sono riportati alcuni stati del thread comune per Aurora My. SQL
- Verifica delle autorizzazioni
-
Il thread sta verificando se il server dispone dei privilegi necessari per eseguire l'istruzione.
- controllo della cache delle query per la query
-
Il server sta verificando se la query corrente è presente nella cache delle query.
- ripulito
-
Questo è lo stato finale di una connessione il cui lavoro è completo ma che non è stato chiuso dal client. La soluzione migliore è chiudere esplicitamente la connessione nel codice. Oppure puoi impostare un valore inferiore per
wait_timeout
nel gruppo di parametri. - chiusura tabelle
-
Il thread sta scaricando i dati della tabella modificati su disco e chiude le tabelle utilizzate. Se non si tratta di un'operazione rapida, verificare le metriche di consumo della larghezza di banda di rete rispetto alla larghezza di banda di rete della classe di istanza. Inoltre, verificare che i valori dei parametri per
table_open_cache
etable_definition_cache
il parametro consentano di aprire contemporaneamente una quantità sufficiente di tabelle in modo che il motore non debba aprire e chiudere frequentemente le tabelle. Questi parametri influenzano il consumo di memoria sull'istanza. - conversione in My HEAP ISAM
-
La query sta convertendo una tabella temporanea da memoria a su disco. Questa conversione è necessaria perché le tabelle temporanee create da My SQL nelle fasi intermedie dell'elaborazione delle query sono diventate troppo grandi per la memoria. Verifica i valori di
tmp_table_size
emax_heap_table_size
. Nelle versioni successive, il nome dello stato del thread èconverting HEAP to ondisk
. - conversione HEAP su disco
-
Il thread sta convertendo una tabella temporanea interna da una tabella in memoria a una tabella su disco.
- copia nella tabella tmp
-
Il thread sta elaborando un'istruzione
ALTER TABLE
. Questo stato si verifica dopo che la tabella con la nuova struttura è stata creata ma prima che le righe vengano copiate. Per un thread in questo stato, è possibile utilizzare lo schema delle prestazioni per ottenere informazioni sullo stato di avanzamento dell'operazione di copia. - creazione di indice di ordinamento
-
Aurora My esegue SQL un ordinamento perché non può utilizzare un indice esistente per soddisfare la
GROUP BY
clausolaORDER BY
or di una query. Per ulteriori informazioni, consulta creazione di indice di ordinamento. - Creazione di tabelle
-
Il thread sta creando una tabella permanente o temporanea.
- commit ritardato ok fatto
-
Un commit asincrono in Aurora My SQL ha ricevuto un riconoscimento ed è completo.
- ritardato commit ok avviato
-
Il SQL thread Aurora My ha avviato il processo di commit asincrono ma è in attesa di conferma. Di solito questo è il tempo di commit autentico di una transazione.
- invio ritardato ok fatto
-
Un SQL thread di lavoro Aurora My collegato a una connessione può essere liberato mentre viene inviata una risposta al client. Il thread può iniziare altri lavori. Lo stato
delayed send ok
significa che la conferma asincrona al client è stata completata. - invio ritardato ok avviato
-
Un SQL thread di lavoro Aurora My ha inviato una risposta in modo asincrono a un client ed è ora libero di lavorare per altre connessioni. La transazione ha avviato un processo di commit asincrono che non è ancora stato riconosciuto.
- executing
-
Il thread ha iniziato a eseguire un'istruzione.
- liberazione elementi
-
Il thread ha eseguito un comando. Alcuni liberazioni degli elementi eseguiti durante questo stato coinvolgono la cache delle query. Questo stato è solitamente seguito dalla pulizia.
- init
-
Questo stato si verifica prima dell'inizializzazione di
ALTER TABLE
,DELETE
,INSERT
,SELECT
, oppure istruzioniUPDATE
. Le azioni in questo stato includono lo svuotamento del log binario o del log InnoDB e alcune operazioni di pulizia della cache delle query. - Source ha inviato tutti i binlog alla replica; in attesa di ulteriori aggiornamenti
-
Il nodo primario ha terminato la sua parte della replica. Il thread è in attesa di eseguire altre query in modo che possa scrivere nel log binario (binlog).
- apertura tabella
-
Il thread sta tentando di aprire una tabella. Questa operazione è veloce a meno che un'istruzione
ALTER TABLE
oLOCK TABLE
debba finire o superare il valore ditable_open_cache
. - Ottimizzazione
-
Il server sta eseguendo le ottimizzazioni iniziali per una query.
- preparazione
-
Questo stato si verifica durante l'ottimizzazione delle query.
- fine query
-
Questo stato si verifica dopo l'elaborazione di una query ma prima dello stato di liberazione degli elementi.
- rimozione di duplicati
-
Aurora My non è SQL riuscita a ottimizzare un'
DISTINCT
operazione nella fase iniziale di una query. Aurora My SQL deve rimuovere tutte le righe duplicate prima di inviare il risultato al client. - ricerca di righe per l'aggiornamento
-
Il thread sta trovando tutte le righe corrispondenti prima di aggiornarle. Questa fase è necessaria se il
UPDATE
sta cambiando l'indice utilizzato dal motore per trovare le righe. - invio dell'evento binlog a slave
-
Il thread ha letto un evento dal log binario e lo sta inviando alla replica.
- invio di risultati memorizzati nella cache al client
-
Il server sta prendendo il risultato di una query dalla cache delle query e la invia al client.
- Invio dei dati
-
Il thread sta leggendo ed elaborando le righe per un'istruzione
SELECT
ma non ha ancora iniziato a inviare dati al client. Il processo sta identificando quali pagine contengono i risultati necessari per soddisfare la query. Per ulteriori informazioni, consulta invio dei dati. - invio al client
-
Il server sta scrivendo un pacchetto sul client. Nelle SQL versioni precedenti di My, questo evento di attesa era etichettato.
writing to net
- avvio in corso
-
Questa è la prima fase all'inizio dell'esecuzione dell'istruzione.
- statistiche
-
Il server sta calcolando le statistiche per sviluppare un piano di esecuzione delle query. Se un thread è in questo stato per un lungo periodo, il server è probabilmente associato a disco durante l'esecuzione di altri lavori.
- archiviazione dei risultati nella cache delle query
-
Il server sta memorizzando il risultato di una query nella cache delle query.
- blocco del sistema
-
Il thread ha chiamato
mysql_lock_tables
, ma lo stato del thread non è stato aggiornato dalla chiamata. Questo stato generale si verifica per molte ragioni. - aggiorna
-
Il thread si sta preparando per iniziare ad aggiornare la tabella.
- aggiornamento
-
Il thread sta cercando righe e le sta aggiornando.
- blocco utente
-
Il thread ha emesso una chiamata
GET_LOCK
. Il thread ha richiesto un blocco consultivo e lo sta aspettando o sta pianificando di richiederlo. - in attesa di ulteriori aggiornamenti
-
Il nodo primario ha terminato la sua parte della replica. Il thread è in attesa di eseguire altre query in modo che possa scrivere nel log binario (binlog).
- in attesa del blocco dei metadati dello schema
-
Questa è un'attesa per un blocco dei metadati.
- in attesa del blocco dei metadati della funzione memorizzata
-
Questa è un'attesa per un blocco dei metadati.
- in attesa del blocco dei metadati della procedura archiviata
-
Questa è un'attesa per un blocco dei metadati.
- in attesa dello scarico della tabella
-
Il thread sta eseguendo
FLUSH TABLES
e sta aspettando che tutti i thread chiudano le loro tabelle. Oppure il thread ha ricevuto una notifica che la struttura sottostante per una tabella è cambiata, quindi deve riaprire la tabella per ottenere la nuova struttura. Per riaprire la tabella, il thread deve attendere che tutti gli altri thread abbiano chiuso la tabella. Questa notifica avviene se un altro thread ha utilizzato una delle seguenti istruzioni sulla tabella:FLUSH TABLES
,ALTER TABLE
,RENAME TABLE
,REPAIR TABLE
,ANALYZE TABLE
, oppureOPTIMIZE TABLE
. - in attesa di blocco a livello tabella
-
Una sessione tiene un blocco su un tavolo mentre un'altra sessione tenta di acquisire lo stesso blocco sulla stessa tabella.
- in attesa del blocco dei metadati della tabella
-
Aurora My SQL utilizza il blocco dei metadati per gestire l'accesso simultaneo agli oggetti del database e garantire la coerenza dei dati. In questo evento di attesa, una sessione tiene un blocco di metadati su una tabella mentre un'altra sessione tenta di acquisire lo stesso blocco sulla stessa tabella. Quando lo schema delle prestazioni è abilitato, questo stato del thread viene segnalato come evento di attesa
synch/cond/sql/MDL_context::COND_wait_status
. - scrittura su rete
-
Il server sta scrivendo un pacchetto sulla rete. Nelle SQL versioni successive di My, questo evento di attesa è etichettato.
Sending to client