Questa pagina descrive Calíope 1.5, la versione che sto costruendo adesso. La 1.4 è sull'App Store per Mac, iPad, iPhone, Apple Watch, Apple TV e Apple Vision Pro. Il changelog dice in quale versione è arrivata ogni funzione.
Aggiunge a ogni argomento un pulsante «Apri in Calíope». Funziona solo con l'app installata.
Quello che il server ha annotato da sé sulle query che hanno superato la sua soglia, per tutti i suoi client.
Dove si trova: Workspace › Strumenti › Query lente
Questo è ciò che il server ha annotato da sé: le query che hanno superato la sua soglia, di tutti i suoi client e non solo di Calíope. Il registro delle query dell'app è un'altra cosa —quello che hai eseguito da qui— e ha uno strumento tutto suo.
La barra offre fino a tre viste, e quali esistono lo decide il server: Impostazioni, sempre; Voci, una riga per esecuzione, solo se il motore conserva le singole esecuzioni e permette a un client di leggerle; Per istruzione, il riepilogo raggruppato per forma della query, solo se il motore lo pubblica. Una vista che il server non può riempire non viene disegnata in grigio: non viene disegnata.
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.
PostgreSQL
PostgreSQL non conserva esecuzioni leggibili da un client: il suo log va in un file della macchina del server. Quello che pubblica è l'aggregato, con pg_stat_statements, quindi qui vedrai Per istruzione e non Voci.
SQL Server
SQL Server non ha un registro delle query lente: né soglia né esecuzioni registrate. Quello che tiene, sempre e senza accendere nulla, è il conteggio di ogni piano nella sua cache, ed è ciò che vedrai in Per istruzione. Voci non compare.
Per vedere una riga intera —il testo completo e tutto ciò che il server ha annotato— fai doppio clic su di essa sul Mac o toccala su iPad. Dalla sua scheda la query si copia o si porta nell'editor.
Il selettore di destra dice quante righe vengono chieste: cinquanta per vedere cosa sta succedendo ora, mille per rivedere la giornata intera. L'aggiornamento automatico rilegge ogni dieci secondi, e la barra dice a che ora è stato letto quello che stai guardando.
Parole chiave: query lente, slow query log, prestazioni, server, soglia, registro
Accendere il registro, spostare la soglia e scegliere dove scrive — dove il server lo consenta da qui.
Dove si trova: Query lente › Impostazioni
Le schede in alto dicono quello che il server risponde in questo momento: se sta registrando, con quale soglia e dove scrive. Sotto compare una di due cose: i controlli per cambiarlo, o una nota che dice dove si cambia davvero. Mai i controlli spenti, che non distinguono «qui no» da «questo è rotto».
La soglia si digita o si sposta con i pulsanti meno e più, e si invia con Applica. Una soglia negativa viene rifiutata qui: nessuna query dura meno di niente, e il server la taglierebbe a zero senza dire nulla — con il risultato che ogni query diventerebbe lenta e il registro crescerebbe senza freni.
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.
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: PostgreSQL scrive sempre nel suo log, che è un file della macchina del server.
SQL Server
In SQL Server non c'è nulla da regolare: la cache dei piani tiene il conto sempre, e non ha né soglia né destinazione da scegliere. Per questo la scheda della soglia non compare e vedrai la nota al posto dei controlli. Quello che si legge vive nella memoria del server: si perde al riavvio, e un piano che esce dalla cache si porta via i suoi numeri. Con optimize for ad hoc workloads acceso, una query isolata entra solo alla seconda esecuzione.
L'elenco finale sono le variabili che questo server pubblica intorno al registro, con il nome che dà loro. Sono informative: si cambiano dove si cambiano le loro impostazioni, non qui.
Parole chiave: soglia, long_query_time, log_min_duration_statement, log_output, ALTER SYSTEM, parameter group
Raggruppa per forma della query, non per esecuzione: dice cosa sta costando la giornata al server.
Dove si trova: Query lente › Per istruzione
Per istruzione non elenca esecuzioni: raggruppa per la forma della query. I letterali vengono sostituiti da un segnaposto, quindi mille query che differiscono solo nel valore cercato sono una riga, con le sue chiamate, il suo tempo totale e il suo tempo medio. È la risposta a «cosa sta costando la giornata a questo server?», che quasi mai è la query più lenta di tutte.
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.
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.
Il riepilogo è di tutto il server, quindi i privilegi contano: dove il tuo utente non può leggere le query degli altri, il server restituisce la riga senza il testo. Quando succede, qui viene detto con il numero —quante altre forme non puoi leggere—, che è molto diverso da un elenco vuoto.
Azzera statistiche mette quei contatori a zero per tutto il server, non per la tua sessione: riguarda chiunque stia guardando lo stesso riepilogo, e non si può annullare.
Parole chiave: riepilogo, per istruzione, performance_schema, pg_stat_statements, normalizzata, privilegi
Il registro dice quale query è lenta; per sapere perché, la si porta nell'editor e la si profila lì.
Dove si trova: Query lente › clic destro › Porta nell'editor
Il registro dice quale query è lenta. Per sapere perché, la query deve essere eseguita di nuovo, e questa è una tua decisione — non di un elenco che si aggiorna ogni dieci secondi.
Da una riga, con il suo menu contestuale o aprendo la sua scheda, Porta nell'editor lascia la query nell'Editor SQL, in una scheda, senza eseguirla. Lì decidi tu cosa farne.
MySQLMariaDBAurora
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, è della famiglia MySQL e qui non compare nell'editor.
Prima di eseguire quello che porta una riga, ricorda che il testo è quello eseguito da un altro client, con i suoi parametri e contro il database che aveva aperto.
MySQLMariaDBAuroraPostgreSQL
E dal riepilogo per istruzione arriva la forma normalizzata, con segnaposto invece dei valori: devi metterci valori tuoi prima di eseguirla.
SQL Server
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.
Parole chiave: profilare, profilatore, editor, explain, piano, porta nell'editor