产品中心
如何轻松找到那些对 DBA 们来说可能是噩梦般的长事务（请参阅 MySQL History List Length post ）。
SELECT thr.processlist_id AS mysql_thread_id, concat(PROCESSLIST_USER,'@',PROCESSLIST_HOST) User, Command, FORMAT_PICO_TIME(trx.timer_wait) AS trx_duration, current_statement as `latest_statement`FROM performance_schema.events_transactions_current trxINNER JOIN performance_schema.threads thr USING (thread_id)LEFT JOIN sys.processlist p ON p.thd_id=thread_id WHERE thr.processlist_id IS NOT NULLAND PROCESSLIST_USER IS NOT NULLAND trx.state = 'ACTIVE' GROUP BY thread_id, timer_waitORDER BY TIMER_WAIT DESC LIMIT 10;
我们可以看到，目前有一个活跃的事务运行超过了 43 分钟仍然没有响应。
休眠状态可能会导致更多问题，它们可能是被遗忘的交互式会话，默认情况下会保持很长时间（8 小时， interactive_timeout).
如果启用了历史记录，还可以查询出在此事务的关联执行语句（默认限制为 10 个， performance_schema_events_statements_history_size) ：
UPDATE performance_schema.setup_consumersSET enabled = 'yes' WHERE name LIKE 'events_statements_history_long'OR name LIKE 'events_transactions_history_long';确认已经启用，而后我们可以使用以下SQL查出新事务之前的历史执行语句：
SELECT DATE_SUB(now(), INTERVAL ( SELECT variable_valueFROM performance_schema.global_statusWHERE variable_name='UPTIME')-TIMER_START*10e-13 second) `start_time`, SQL_TEXT FROM performance_schema.events_statements_history WHERE nesting_event_id=( SELECT EVENT_IDFROM performance_schema.events_transactions_current tLEFT JOIN sys.processlist p ON p.thd_id=t.thread_id WHERE conn_id=<VALUE OF mysql_thread_id COLUMN>)ORDER BY event_id;让我们尝试一下：
如您所见，结果显示已经查询出此长事务之前执行的SQL语句。
再次强调，Performance_Schema 可以帮忙我们更准确的确定性能问题原因。
避免长事务才可更好的发挥MySQL的潜能！
