Esta página describe Calíope 1.8, la versión que estoy construyendo ahora mismo. La 1.7 está en la App Store para Mac, iPad, iPhone, Apple Watch, Apple TV y Apple Vision Pro. El changelog dice en qué versión llegó cada función.
Añade un botón «Abrir en Calíope» a cada tema. Sólo funciona con la app instalada.
Lo que el servidor grabó por su cuenta de las consultas que pasaron de su umbral, de todos sus clientes.
Dónde está: Espacio de Trabajo › Herramientas › Consultas lentas
Esto es lo que el servidor anotó por su cuenta: las consultas que pasaron de su umbral, de todos sus clientes y no sólo de Calíope. El registro de consultas de la app es otra cosa —lo que ejecutaste tú desde aquí— y vive en su propia herramienta.
La barra ofrece hasta tres vistas, y cuáles existen depende del servidor: Ajustes, siempre; Entradas, una fila por ejecución, sólo si el motor guarda ejecuciones concretas y las deja leer desde un cliente; Por sentencia, el resumen agrupado por forma de consulta, sólo si el motor lo publica. La vista que el servidor no puede dar no se dibuja apagada: no se dibuja.
MySQLMariaDBAurora
La familia MySQL da las dos cosas: mysql.slow_log guarda ejecuciones —con su hora, su usuario y el texto literal— y performance_schema guarda el resumen por forma.
TiDB
TiDB da las dos cosas, de otras tablas: las ejecuciones salen de CLUSTER_SLOW_QUERY, que lee el archivo tidb-slow.log de cada nodo —sin las consultas que TiDB lanza por su cuenta—, y el resumen por forma, de STATEMENTS_SUMMARY.
PostgreSQL
PostgreSQL escribe las ejecuciones a su archivo de log, y Calíope lo lee por SQL (pg_ls_logdir() y pg_read_binary_file()) cuando el servidor tiene el recolector encendido (logging_collector = on), un formato de una fila por ejecución (jsonlog o csvlog en log_destination) y tu cuenta puede leerlo (pg_monitor y pg_read_server_files); si falta algo, Entradas dice qué. El agregado lo publica pg_stat_statements, en Por sentencia.
SQL Server
SQL Server no tiene registro de consultas lentas propio, así que Calíope crea uno: una sesión de Extended Events, caliope_slow_statements, que graba cada sentencia que pasa del umbral. Ésas son las Entradas, y la sesión se enciende desde Ajustes. Por sentencia es otra cosa: la cuenta que el servidor lleva siempre de cada plan que tiene en caché.
Para ver una fila entera —el texto completo y todo lo que el servidor anotó de ella— haz doble clic sobre ella en el Mac o tócala en el iPad. Desde su ficha se copia la consulta o se lleva al editor.
El selector de la derecha dice cuántas filas se piden: cincuenta para ver qué está pasando ahora, mil para revisar el día entero. El auto-refresco relee cada diez segundos, y la barra dice a qué hora se leyó lo que estás viendo.
Oracle
Oracle no tiene registro de consultas lentas: ni umbral del servidor ni ejecuciones grabadas una a una. Lo que se lee es la caché de sentencias (V$SQL), que lleva siempre la cuenta de cada sentencia mientras sigue en ella. Entradas enseña una fila por sentencia en su ejecución media —tiempo, CPU, lecturas y filas divididos entre el número de ejecuciones, que va al lado— y Por sentencia, el resumen agrupado por forma. No es un historial: una sentencia que sale de la caché desaparece con sus cifras, y un reinicio la vacía. Las consultas internas de SYS y SYSTEM no salen, salvo las tuyas si entras con una de esas cuentas. Leer V$SQL pide un privilegio de diccionario (SELECT_CATALOG_ROLE o SELECT ANY DICTIONARY); sin él, la pantalla enseña el error del servidor. AWR y las vistas DBA_HIST_* no se consultan: exigen un paquete de pago de Oracle. Ocultar las de Calíope esconde lo que Calíope consulta por su cuenta —sus sentencias llevan delante la marca /*Caliope*/—, nunca lo que escribiste en el editor.
ClickHouse
ClickHouse da las dos cosas desde system.query_log: las ejecuciones, leídas justo después de un SYSTEM FLUSH LOGS para que lo recién ejecutado ya esté, y el resumen por forma. Las ejecuciones incluyen las que fallaron, con su error en una columna propia, y traen los bytes leídos y la memoria detrás del tiempo; la hora es la del reloj del servidor. Ocultar las de Calíope, encendida por omisión, esconde lo que Calíope consulta por su cuenta, nunca lo que escribiste en el editor.
Apple Vision Pro: como en el iPad: mira la fila y pellizca para abrirla.
Encender el registro, mover el umbral y elegir dónde escribe — donde el servidor deje hacerlo desde aquí.
Dónde está: Consultas lentas › Ajustes
Las tarjetas de arriba dicen lo que el servidor contesta ahora mismo: si está grabando, con qué umbral y dónde escribe. Debajo aparece una de dos cosas: los controles para cambiarlo, o una nota que dice dónde se cambia de verdad. Nunca los controles apagados, que no distinguen «aquí no» de «esto está roto».
El umbral se teclea o se mueve con los botones de menos y más, y se manda con Aplicar. Uno negativo se rechaza aquí mismo: ninguna consulta dura menos que nada, y el servidor no lo rechazaría: según el motor, lo recorta a cero —con lo que toda consulta pasaría a ser lenta y el registro crecería sin freno— o lo convierte en otro valor sin avisar.
MySQLMariaDBAurora
El umbral va en segundos (long_query_time), y el destino se elige entre la tabla mysql.slow_log, el archivo del servidor o los dos (log_output). Sólo lo que va a la tabla se puede leer desde un cliente.
Dos cosas que sorprenden: un cambio hecho desde aquí no sobrevive a un reinicio del servidor —para eso va en su archivo de configuración— y no alcanza a las conexiones ya abiertas, tampoco a la de Calíope: las sesiones vivas siguen midiendo con el valor anterior hasta que se reciclan.
Aurora
En Amazon Aurora estos ajustes no viven en el servidor sino en el grupo de parámetros del clúster, así que aquí verás la nota en lugar de los controles. Vaciar el registro sí se puede: lo hace el propio servidor con mysql.rds_rotate_slow_log.
TiDB
El umbral es tidb_slow_log_threshold, y el servidor lo lleva en milisegundos: aquí se escribe en segundos, como en los demás motores, y la lista del final enseña el valor del servidor con su unidad. long_query_time existe y no gobierna nada. Un negativo, en TiDB, da la vuelta y queda un umbral tan alto que no se graba nada.
El destino no se elige: TiDB escribe siempre al archivo de cada nodo y lo publica como tabla. Un cambio hecho desde aquí alcanza en el acto a todas las conexiones de ese nodo, también a la de Calíope, y dura hasta que el nodo se reinicie: entonces vuelve al valor de su configuración.
PostgreSQL
El umbral va en milisegundos (log_min_duration_statement), y un cambio hecho desde aquí sí persiste: se escribe con ALTER SYSTEM y el servidor recarga su configuración.
Pero hay orígenes que le ganan sin decirlo. Si el valor viene de la línea de órdenes con la que arrancó el servidor, o de un ajuste propio de esta base, de este rol o de esta sesión, la escritura se acepta, el archivo queda con el valor nuevo y el que rige sigue siendo el de antes. Por eso la primera variable de la lista del final es el origen del umbral: es lo que dice dónde hay que cambiarlo. Cuando el origen es uno de ésos, aquí verás la nota y no los controles.
El destino no se elige desde aquí: PostgreSQL escribe siempre a su propio log, un archivo de la máquina del servidor, y Entradas lo lee por SQL si el recolector y el formato están puestos.
SQL Server
En SQL Server el interruptor crea y arranca la sesión de Extended Events caliope_slow_statements, o la para. Es del servidor entero: graba las sentencias de todas las conexiones, y con STARTUP_STATE = ON vuelve a arrancar con él. El umbral es su predicado (duration, en microsegundos en el servidor), y Escribe en elige entre La memoria del servidor, hasta que reinicie (un ring_buffer, que guarda unas mil) y Un archivo del servidor (un event_file en su directorio de datos). Cambiarla pide el permiso ALTER ANY EVENT SESSION, y sin él la negativa lo nombra; leer, VIEW SERVER STATE. Ocultar las de Calíope esconde lo que Calíope consulta por su cuenta, que lleva la marca /*Caliope*/; lo que escribes en el editor se ve siempre. El resumen Por sentencia sigue saliendo de la caché de planes: se pierde al reiniciar el servidor, y con optimize for ad hoc workloads encendido una consulta suelta no entra hasta su segunda ejecución.
La lista del final son las variables que este servidor publica alrededor del registro, con el nombre que él les da. Son informativas: se cambian donde se cambien sus ajustes, no aquí.
Oracle
En Oracle el umbral es de Calíope, no del servidor: se aplica al leer, a la ejecución media de cada sentencia, y se guarda en este perfil. Cambiarlo no toca nada en el servidor y rige en la lectura siguiente. Va en segundos, aunque la caché cuenta el tiempo en microsegundos; si no lo has cambiado, es un segundo. No hay interruptor —la caché no se apaga— ni destino que elegir: lo que se lee vive en la memoria del servidor.
ClickHouse
El servidor lleva el umbral en milisegundos (log_queries_min_query_duration_ms), aunque aquí se enseña en segundos, y el destino es siempre system.query_log. El encendido y el umbral se guardan en tu propia cuenta, con ALTER USER … MODIFY SETTINGS, y rigen para las consultas de esa cuenta desde la siguiente, no para las de las demás. Si la cuenta está definida en la configuración del servidor o no tiene ALTER USER, verás la nota en lugar de los controles. Vaciar el registro es TRUNCATE TABLE system.query_log, del servidor entero. Debajo, Variables que afinan el registro lista seis ajustes de lo que se guarda de cada consulta —desde qué etapa (log_queries_min_type), qué fracción (log_queries_probability), dónde se corta el texto y si se guardan los ajustes, los hilos y las vistas que tocó—, con el valor de tu cuenta; donde la cuenta puede guardar sus ajustes, cada uno lleva un campo y Aplicar, y se escribe como el umbral.
Palabras clave: umbral, long_query_time, log_min_duration_statement, log_output, ALTER SYSTEM, parameter group
Agrupa por forma de consulta, no por ejecución: contesta qué le está costando el día al servidor.
Dónde está: Consultas lentas › Por sentencia
Por sentencia no lista ejecuciones: agrupa por la forma de la consulta. Los literales se sustituyen por un marcador, así que mil consultas que sólo difieren en el valor que buscan son una fila, con sus llamadas, su tiempo total y su tiempo medio. Es lo que contesta «¿qué le está costando el día a este servidor?», que casi nunca es la consulta más lenta de todas.
MySQLMariaDBAurora
Lo publica performance_schema, y los literales salen como ?. En MariaDB nace apagado: si esta vista dice que no hay resumen, no es que no haya consultas lentas — es que performance_schema está en OFF. No se enciende con el servidor en marcha: va en su archivo de configuración y hay que reiniciarlo.
TiDB
Lo publica STATEMENTS_SUMMARY, y los literales salen como ?. No acumula desde el arranque: es la ventana en curso, que el servidor cierra y vuelve a abrir cada tidb_stmt_summary_refresh_interval segundos (1800 por omisión), así que las llamadas cuentan desde que empezó esa ventana. Si el resumen está apagado (tidb_enable_stmt_summary), se enciende sin reiniciar, con SET GLOBAL. Reiniciar estadísticas no aparece: no hay sentencia que lo vacíe.
PostgreSQL
Lo publica pg_stat_statements, y los literales salen como $1. Necesita dos cosas, y las dos fuera de la app: la biblioteca precargada en shared_preload_libraries, que exige reiniciar el servidor, y la extensión creada en esta base, una vez por base:
CREATE EXTENSION pg_stat_statements;
Si la extensión está creada y la biblioteca no está cargada, la vista existe y no recoge nada. Son dos estados distintos, y la herramienta los dice por separado.
SQL Server
Lo publica sys.dm_exec_query_stats, agrupado por query_hash, que es la forma de la consulta. El texto que ves es el de una de sus ejecuciones, con sus literales, no una forma con marcadores. Leerlo pide el permiso VIEW SERVER STATE; sin él, la vista enseña el error del servidor. Reiniciar estadísticas no aparece: vaciar este resumen sería DBCC FREEPROCCACHE, que tira los planes de todo el servidor, y eso no se hace desde aquí.
El resumen es del servidor entero, así que los privilegios importan: donde tu usuario no puede leer las consultas de los demás, el servidor devuelve la fila sin el texto. Cuando eso pasa, aquí se dice con el número —cuántas formas más hay que no puedes leer—, que es muy distinto de una lista vacía.
Reiniciar estadísticas pone esos contadores a cero para todo el servidor, no para tu sesión: afecta a cualquiera que esté mirando el mismo resumen, y no se puede deshacer.
Oracle
Sale de V$SQL, agrupado por FORCE_MATCHING_SIGNATURE: dos consultas que sólo cambian en un literal son una fila, y el texto que ves es el de una de ellas. Las sentencias sin esa firma —los bloques PL/SQL, el DDL— se agrupan por su SQL_ID. El resumen no aplica el umbral, y el máximo es el de la ejecución media más lenta de las que agrupa: la caché no guarda cada ejecución. Reiniciar estadísticas no aparece, ni Vaciar el log en Entradas: los dos serían vaciar la caché compartida de todo el servidor.
ClickHouse
Sale de system.query_log, agrupado por normalized_query_hash: dos consultas que sólo cambian en un literal son una fila, y el texto que ves es el de una de ellas. Reiniciar estadísticas vacía esa misma tabla, así que se lleva también las ejecuciones, y la confirmación lo dice.
Palabras clave: resumen, por sentencia, performance_schema, pg_stat_statements, normalizada, privilegios
El registro dice qué consulta va lenta. Para saber por qué, la consulta tiene que volver a ejecutarse, y eso es una decisión tuya — no de una lista que se refresca cada diez segundos.
Desde una fila, con su menú contextual o abriendo su ficha, Llevar al editor deja la consulta en el Editor SQL, en una pestaña, sin ejecutarla. Allí decides qué hacer con ella.
MySQLMariaDBAuroraClickHouseOracle
Ejecutarla y pulsar Perfilar para ver el desglose por fases, o pedirle el plan al motor con EXPLAIN visual.
PostgreSQLSQL Server
Pedirle el plan al motor con EXPLAIN visual. Perfilar, el desglose por fases, no aparece en el editor: este motor no lo da.
TiDB
Pedirle el plan al motor con EXPLAIN visual. Perfilar, el desglose por fases, no aparece en el editor: TiDB no lo tiene.
Antes de ejecutar lo que trae una fila, recuerda que el texto es el que ejecutó otro cliente, con sus parámetros y contra la base que él tenía abierta.
MySQLMariaDBAuroraPostgreSQLTiDB
Y del resumen por sentencia lo que llega es la forma normalizada, con marcadores en lugar de valores: hay que poner valores propios antes de ejecutarla.
SQL ServerClickHouseOracle
Del resumen por sentencia lo que llega es el texto de una de sus ejecuciones, con los valores de ésa: la fila representa a todas las de la misma forma.
Palabras clave: perfilar, perfilador, editor, explain, plan, llevar al editor
Qué se lleva cada botón en el servidor y en qué motores aparece.
Dónde está: Espacio de Trabajo › Herramientas › Consultas lentas
Dos botones borran lo que el servidor ha grabado, y ninguno se deshace.
- Vaciar el log, en Entradas, borra las ejecuciones grabadas.
- Reiniciar estadísticas, en Por sentencia, pone a cero el resumen de todo el servidor, no sólo el tuyo.
Las dos confirmaciones dicen cuántas filas se van, contadas en el servidor antes de preguntar, y pasan por la protección de la etiqueta de entorno. Salen sólo donde el motor lo permite y la sesión puede escribir.
MySQLMariaDBAurora
Con MySQL, MariaDB y Aurora están los dos botones.
PostgreSQL
Con PostgreSQL sólo está poner a cero las estadísticas: las ejecuciones son el log del servidor, que un cliente no borra; lo rota el servidor.
ClickHouse
Con ClickHouse están los dos, y poner a cero las estadísticas también borra las ejecuciones, porque son la misma tabla.
Oracle
Con Oracle no se ofrece ninguno.
SQL Server
Con SQL Server, Vaciar el log para y arranca la sesión, que vacía la memoria; si escribe en un archivo, la pasa a uno nuevo, y el anterior se queda en el directorio de datos del servidor sin volver a leerse. Reiniciar estadísticas no aparece: sería DBCC FREEPROCCACHE, que tira los planes de todo el servidor.
TiDB
Con TiDB no se ofrece ninguno: el registro es un archivo de cada nodo, y el resumen se renueva solo con cada ventana.