O que está rodando agora: sessões ativas, latência, locks e transações (sys.session)
MySQLDesempenhoComando
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;O que faz
Enriquece o SHOW PROCESSLIST com dados do performance_schema: latência do statement em execução, percentual de progresso, tempo de espera por lock, linhas examinadas, informações de full scan / tabela temporária em disco e estado da transação aberta em uma só linha. Também lista sessões em Sleep que mantêm uma transação aberta.
Quando usar
Nos primeiros 30 segundos de um incidente: qual consulta está rodando há quanto tempo, quem está esperando por locks, qual sessão ociosa mantém uma transação aberta.
Atenção
sys.session faz vários joins sobre o performance_schema; com milhares de conexões a própria consulta pode levar segundos, então use as views x$ e LIMIT para monitoramento frequente. progress só é preenchido com os instrumentos de stage habilitados e para operações que reportam progresso, como ALTER. Uma sessão em Sleep com trx_state=ACTIVE é uma transação esquecida por uma aplicação / pool de conexões usando autocommit=0, a causa mais comum de problemas de metadata lock e purge.
Relacionados
- Encontrar as consultas mais caras (digest do performance_schema)
- Diagnosticar 'Waiting for table metadata lock' e encontrar o verdadeiro bloqueador
- Analisar deadlocks do InnoDB e registrar todos eles
- Transações de longa duração e history list length (atraso do purge)
- Capturar um slow log completo curto e analisá-lo com pt-query-digest
- Depurar um plano ruim com EXPLAIN ANALYZE e o optimizer trace