Esta página describe Calíope 1.5, la versión que estoy construyendo ahora mismo. La 1.4 ya 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.
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í.
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.
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.
MySQLMariaDBAurora
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, 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 Server
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