Qué se está ejecutando ahora: sesiones activas, latencia, bloqueos y transacciones (sys.session)
MySQLRendimientoComando
SELECT conn_id, user, db, command, state, time,
LEFT(current_statement, 100) AS current_statement,
statement_latency, progress, lock_latency,
rows_examined, full_scan, tmp_disk_tables,
trx_state, trx_latency, last_wait
FROM sys.session
WHERE command <> 'Sleep' OR trx_state = 'ACTIVE'
ORDER BY time DESC
LIMIT 25;Qué hace
Enriquece SHOW PROCESSLIST con datos de performance_schema: latencia de la sentencia en ejecución, porcentaje de progreso, tiempo de espera de bloqueo, filas examinadas, información de full scan / tabla temporal en disco y estado de la transacción abierta en una sola fila. También lista las sesiones en Sleep que mantienen una transacción abierta.
Cuándo usarlo
En los primeros 30 segundos de un incidente: qué consulta lleva cuánto tiempo ejecutándose, quién espera bloqueos, qué sesión inactiva mantiene una transacción abierta.
Precaución
sys.session realiza varios joins sobre performance_schema; con miles de conexiones la propia consulta puede tardar segundos, así que use las vistas x$ y LIMIT para el monitoreo frecuente. progress solo se rellena con los instrumentos de stage habilitados y para operaciones que reportan progreso, como ALTER. Una sesión en Sleep con trx_state=ACTIVE es una transacción olvidada por una aplicación / pool de conexiones que usa autocommit=0, la causa más común de problemas de metadata lock y purge.
Relacionado
- Encontrar las consultas más costosas (performance_schema digest)
- Diagnosticar 'Waiting for table metadata lock' y encontrar el bloqueador real
- Analizar los deadlocks de InnoDB y registrarlos todos
- Transacciones de larga duración e history list length (retraso de purge)
- Capturar un slow log completo breve y analizarlo con pt-query-digest
- Depurar un mal plan con EXPLAIN ANALYZE y el optimizer trace