教你 MySQL 8.0 数据库 如何轻松定位长事务

如何轻松找到那些对 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 trx  INNER 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 NULL    AND PROCESSLIST_USER IS NOT NULL    AND trx.state = 'ACTIVE' GROUP BY thread_id, timer_wait  ORDER BY TIMER_WAIT DESC LIMIT 10;

我们可以看到，目前有一个活跃的事务运行超过了 43 分钟仍然没有响应。

休眠状态可能会导致更多问题，它们可能是被遗忘的交互式会话，默认情况下会保持很长时间（8 小时， interactive_timeout).

如果启用了历史记录，还可以查询出在此事务的关联执行语句（默认限制为 10 个， performance_schema_events_statements_history_size) ：

UPDATE performance_schema.setup_consumers        SET enabled = 'yes'   WHERE name LIKE 'events_statements_history_long'      OR name LIKE 'events_transactions_history_long';

确认已经启用，而后我们可以使用以下SQL查出新事务之前的历史执行语句：

SELECT DATE_SUB(now(), INTERVAL (         SELECT variable_value            FROM performance_schema.global_status            WHERE variable_name='UPTIME')-TIMER_START*10e-13 second) `start_time`,       SQL_TEXT   FROM performance_schema.events_statements_history   WHERE nesting_event_id=(               SELECT EVENT_ID                  FROM performance_schema.events_transactions_current t                    LEFT 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的潜能！