Query lente del server

MySQLMariaDBAurora

La famiglia MySQL dà entrambe le cose: mysql.slow_log conserva le esecuzioni —con la loro ora, il loro utente e il testo letterale— e performance_schema conserva il riepilogo per forma.

TiDB

TiDB dà entrambe le cose, da altre tabelle: le esecuzioni vengono da CLUSTER_SLOW_QUERY, che legge il file tidb-slow.log di ogni nodo —senza le query che TiDB lancia per conto suo—, e il riepilogo per forma da STATEMENTS_SUMMARY.

PostgreSQL

PostgreSQL scrive le esecuzioni nel suo file di log, e Calíope lo legge via SQL (pg_ls_logdir() e pg_read_binary_file()) quando il server ha il collector acceso (logging_collector = on), un formato di una riga per esecuzione (jsonlog o csvlog in log_destination) e il tuo account può leggerlo (pg_monitor e pg_read_server_files); se manca qualcosa, Voci dice cosa. L’aggregato viene da pg_stat_statements, in Per istruzione.

SQL Server

SQL Server non ha un registro delle query lente suo, quindi Calíope ne crea uno: una sessione Extended Events, caliope_slow_statements, che registra ogni istruzione oltre la soglia. Quelle sono le Voci, e la sessione si accende da Impostazioni. Per istruzione è un’altra cosa: il conteggio che il server tiene sempre di ogni piano nella sua cache.

Oracle

Oracle non ha un registro delle query lente: né soglia del server né esecuzioni registrate una per una. Quello che si legge è la cache delle istruzioni (V$SQL), che tiene sempre i numeri di ogni istruzione finché ci resta. Voci mostra una riga per istruzione nella sua esecuzione media —tempo, CPU, letture e righe divisi per il numero di esecuzioni, che sta accanto— e Per istruzione, il riepilogo raggruppato per forma. Non è una cronologia: un'istruzione che esce dalla cache scompare con i suoi numeri, e un riavvio la svuota. Le query interne di SYS e SYSTEM non compaiono, tranne le tue se accedi con uno di quegli account. Leggere V$SQL richiede un privilegio di dizionario (SELECT_CATALOG_ROLE o SELECT ANY DICTIONARY); senza, la schermata mostra l'errore del server. AWR e le viste DBA_HIST_* non vengono interrogati: richiedono un pacchetto a pagamento di Oracle. Nascondi quelle di Calíope nasconde ciò che Calíope interroga per conto suo —le sue istruzioni iniziano con il marchio /*Caliope*/—, mai ciò che hai scritto nell'editor.

ClickHouse

ClickHouse dà entrambe le cose da system.query_log: le esecuzioni, lette subito dopo un SYSTEM FLUSH LOGS perché ciò che è appena stato eseguito ci sia già, e il riepilogo per forma. Le esecuzioni includono quelle fallite, con il loro errore in una colonna a parte, e riportano i byte letti e la memoria dopo il tempo; l'ora è quella dell'orologio del server. Nascondi quelle di Calíope, attiva per impostazione predefinita, nasconde ciò che Calíope interroga per conto suo, mai ciò che hai scritto nell'editor.

MySQLMariaDBAurora

La soglia è in secondi (long_query_time), e la destinazione si sceglie tra la tabella mysql.slow_log, il file del server o entrambi (log_output). Solo quello che va nella tabella si può leggere da un client.

Due cose che sorprendono: una modifica fatta da qui non sopravvive a un riavvio del server —per questo va nel suo file di configurazione— e non raggiunge le connessioni già aperte, nemmeno quella di Calíope: le sessioni vive continuano a misurare con il valore precedente finché non vengono riciclate.

Aurora

Su Amazon Aurora queste impostazioni non vivono nel server ma nel gruppo di parametri del cluster, quindi qui vedrai la nota invece dei controlli. Svuotare il registro si può: lo fa il server stesso con mysql.rds_rotate_slow_log.

TiDB

La soglia è tidb_slow_log_threshold, e il server la tiene in millisecondi: qui si scrive in secondi, come negli altri motori, e l'elenco in fondo mostra il valore del server con la sua unità. long_query_time esiste e non governa nulla. Una soglia negativa, in TiDB, fa il giro e diventa una soglia così alta che non si registra nulla.

La destinazione non si sceglie: TiDB scrive sempre nel file di ogni nodo e lo pubblica come tabella. Una modifica fatta da qui raggiunge subito tutte le connessioni a quel nodo, compresa quella di Calíope, e dura fino al riavvio del nodo: allora torna al valore della sua configurazione.

PostgreSQL

La soglia è in millisecondi (log_min_duration_statement), e una modifica fatta da qui persiste: si scrive con ALTER SYSTEM e il server ricarica la sua configurazione.

Ma ci sono origini che vincono senza dirlo. Se il valore viene dalla riga di comando con cui il server è partito, o da un'impostazione di questo database, di questo ruolo o di questa sessione, la scrittura viene accettata, il file resta con il valore nuovo e quello in vigore è ancora il vecchio. Per questo la prima variabile dell'elenco in fondo è l'origine della soglia: è quella che dice dove va cambiata. Quando l'origine è una di quelle, qui vedrai la nota e non i controlli.

La destinazione non si sceglie da qui: PostgreSQL scrive sempre nel suo log, un file della macchina del server, e Voci lo legge via SQL se il collector e il formato sono impostati.

SQL Server

In SQL Server l’interruttore crea e avvia la sessione Extended Events caliope_slow_statements, oppure la ferma. Vale per tutto il server: registra le istruzioni di tutte le connessioni e, con STARTUP_STATE = ON, riparte con lui. La soglia è il suo predicato (duration, in microsecondi sul server), e Scrive in sceglie tra La memoria del server, fino al riavvio (un ring_buffer, che ne tiene circa mille) e Un file del server (un event_file nella sua cartella dei dati). Cambiarla richiede il permesso ALTER ANY EVENT SESSION, e senza il rifiuto lo nomina; leggerla, VIEW SERVER STATE. Nascondi quelle di Calíope nasconde ciò che Calíope interroga da sé, che porta il segno /*Caliope*/; ciò che scrivi nell’editor si vede sempre. Il riepilogo Per istruzione continua a venire dalla cache dei piani: si perde al riavvio del server, e con optimize for ad hoc workloads attivo una query isolata entra solo alla seconda esecuzione.

Oracle

In Oracle la soglia è di Calíope, non del server: si applica alla lettura, all'esecuzione media di ogni istruzione, e viene salvata in questo profilo. Cambiarla non tocca nulla sul server e vale dalla lettura successiva. È in secondi, anche se la cache conta il tempo in microsecondi; se non l'hai cambiata, è un secondo. Non c'è interruttore —la cache non si spegne— né destinazione da scegliere: ciò che si legge vive nella memoria del server.

ClickHouse

Il server tiene la soglia in millisecondi (log_queries_min_query_duration_ms), anche se qui si mostra in secondi, e la destinazione è sempre system.query_log. L'attivazione e la soglia si salvano nel tuo stesso account, con ALTER USER … MODIFY SETTINGS, e valgono per le query di quell'account dalla successiva, non per quelle degli altri. Se l'account è definito nella configurazione del server o non ha ALTER USER, vedrai la nota invece dei controlli. Svuotare il registro è TRUNCATE TABLE system.query_log, per tutto il server. Sotto, Variabili che affinano il registro elenca sei impostazioni di ciò che si conserva di ogni query —da quale fase (log_queries_min_type), quale frazione (log_queries_probability), dove si taglia il testo e se si conservano le impostazioni, i thread e le viste che ha toccato—, con il valore del tuo account; dove l'account può salvare le sue impostazioni, ognuna ha un campo e Applica, e si scrive come la soglia.

MySQLMariaDBAurora

Lo pubblica performance_schema, e i letterali escono come ?. Su MariaDB nasce spento: se questa vista dice che non c'è riepilogo, non è che non ci siano query lente — è che performance_schema è su OFF. Non si accende con il server in marcia: va nel suo file di configurazione e bisogna riavviarlo.

TiDB

Lo pubblica STATEMENTS_SUMMARY, e i letterali escono come ?. Non accumula dall'avvio: è la finestra in corso, che il server chiude e riapre ogni tidb_stmt_summary_refresh_interval secondi (1800 di default), quindi le chiamate contano dall'inizio di quella finestra. Se il riepilogo è spento (tidb_enable_stmt_summary), si accende senza riavviare, con SET GLOBAL. Azzera statistiche non compare: non c'è un'istruzione che lo svuoti.

PostgreSQL

Lo pubblica pg_stat_statements, e i letterali escono come $1. Servono due cose, entrambe fuori dall'app: la libreria precaricata in shared_preload_libraries, che richiede di riavviare il server, e l'estensione creata in questo database, una volta per database:

CREATE EXTENSION pg_stat_statements;

Se l'estensione è creata e la libreria non è caricata, la vista esiste e non raccoglie niente. Sono due stati diversi, e lo strumento dice quale.

SQL Server

Lo pubblica sys.dm_exec_query_stats, raggruppato per query_hash, che è la forma della query. Il testo che vedi è quello di una delle sue esecuzioni, con i suoi letterali, non una forma con segnaposto. Leggerlo richiede il permesso VIEW SERVER STATE; senza, la vista mostra l'errore del server. Azzerare le statistiche non compare: svuotare questo riepilogo sarebbe DBCC FREEPROCCACHE, che butta i piani di tutto il server, e non si fa da qui.

Oracle

Viene da V$SQL, raggruppato per FORCE_MATCHING_SIGNATURE: due query che differiscono solo per un letterale sono una riga, e il testo che vedi è quello di una di esse. Le istruzioni senza quella firma —i blocchi PL/SQL, il DDL— si raggruppano per il loro SQL_ID. Il riepilogo non applica la soglia, e il massimo è quello dell'esecuzione media più lenta tra quelle raggruppate: la cache non conserva ogni esecuzione. Azzerare le statistiche non compare, né Svuotare il registro in Voci: entrambi vorrebbero dire svuotare la cache condivisa di tutto il server.

ClickHouse

Viene da system.query_log, raggruppato per normalized_query_hash: due query che differiscono solo per un letterale sono una riga, e il testo che vedi è quello di una di esse. Azzerare le statistiche svuota quella stessa tabella, quindi si porta via anche le esecuzioni, e la conferma lo dice.

MySQLMariaDBAuroraClickHouseOracle

Eseguirla e premere Profila per vedere la scomposizione per fasi, o chiedere al motore il suo piano con EXPLAIN visuale.

PostgreSQLSQL Server

Chiedere al motore il suo piano con EXPLAIN visuale. Profila, la scomposizione per fasi, non compare nell’editor: questo motore non la fornisce.

TiDB

Chiedere al motore il suo piano con EXPLAIN visuale. Profila, la scomposizione per fasi, non compare nell'editor: TiDB non ce l'ha.

MySQLMariaDBAuroraPostgreSQLTiDB

E dal riepilogo per istruzione arriva la forma normalizzata, con segnaposto invece dei valori: devi metterci valori tuoi prima di eseguirla.

SQL ServerClickHouseOracle

Dal riepilogo per istruzione arriva il testo di una delle sue esecuzioni, con i valori di quella: la riga rappresenta tutte quelle della stessa forma.

MySQLMariaDBAurora

Con MySQL, MariaDB e Aurora ci sono entrambi i pulsanti.

PostgreSQL

Con PostgreSQL c’è solo l’azzeramento delle statistiche: le esecuzioni sono il log del server, che un client non cancella; lo ruota il server.

ClickHouse

Con ClickHouse ci sono entrambi, e azzerare le statistiche elimina anche le esecuzioni, perché sono la stessa tabella.

Oracle

Con Oracle non si offre nessuno dei due.

SQL Server

Con SQL Server, Svuotare il registro ferma e riavvia la sessione, il che svuota la memoria; se scrive su un file, passa a uno nuovo, e il precedente resta nella cartella dei dati del server senza essere riletto. Azzerare le statistiche non compare: sarebbe DBCC FREEPROCCACHE, che butta via i piani di tutto il server.

TiDB

Con TiDB non se ne offre nessuno: il registro è un file di ogni nodo, e il riepilogo si rinnova da solo a ogni finestra.