Esta página describe Calíope 1.5, la versión que estamos construyendo ahora mismo. La 1.4 está terminada y en revisión de App Store, y la tienda sirve hoy la 1.3 en el Mac y la 1.2 en iPad. 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.
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.
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.
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: ejecutarla y pulsar Perfilar para ver el desglose por fases, o pedirle el plan al motor con EXPLAIN visual.
Dos cautelas antes de ejecutar lo que trae una fila. El texto es el que ejecutó otro cliente, con sus parámetros y contra la base que él tenía abierta. 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.
Palabras clave: perfilar, perfilador, editor, explain, plan, llevar al editor