Esta página describe Calíope 1.7, la versión que estoy construyendo ahora mismo. La 1.6 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.
PostgreSQL
PostgreSQL no guarda ejecuciones que un cliente pueda leer: su log va a un archivo de la máquina del servidor. Lo que sí publica es el agregado, con pg_stat_statements, así que aquí verás Por sentencia y no Entradas.
SQL Server
SQL Server no tiene registro de consultas lentas: ni umbral ni ejecuciones grabadas. Lo que sí lleva, siempre y sin encender nada, es la cuenta de cada plan que tiene en caché, y eso es lo que verás en Por sentencia. Entradas no aparece.
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.
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 lo recortaría a cero sin avisar — con lo que toda consulta pasaría a ser lenta y el registro crecería sin freno.
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.
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: PostgreSQL escribe siempre a su propio log, que es un archivo de la máquina del servidor.
SQL Server
En SQL Server no hay nada que ajustar: la caché de planes lleva la cuenta siempre, y no tiene umbral ni destino que elegir. Por eso la tarjeta del umbral no aparece y verás la nota en lugar de los controles. Lo que se lee vive en la memoria del servidor: se pierde al reiniciarlo, y un plan que sale de la caché se lleva sus números. 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.
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.
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.
MySQLMariaDBAuroraClickHouse
Ejecutarla y pulsar Perfilar para ver el desglose por fases, o pedirle el plan al motor con EXPLAIN visual.
PostgreSQLSQL ServerOracle
Pedirle el plan al motor con EXPLAIN visual. Perfilar, el desglose por fases, es de la familia MySQL y aquí no aparece en el editor.
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.
MySQLMariaDBAuroraPostgreSQL
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.
ClickHouse
Con ClickHouse están los dos, y poner a cero las estadísticas también borra las ejecuciones, porque son la misma tabla.