教你 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的潜能！