最直接查看MySQL事务状态的方法是结合SHOW ENGINE INNODB STATUS与information_schema.INNODB_TRX。前者提供活跃事务、锁等待等宏观信息，后者展示每个事务的ID、状态（如RUNNING、LOCK WAIT）、开始时间及执行语句，便于定位阻塞和长事务。通过INNODB_LOCK_WAITS和INNODB_LOCKS可进一步分析锁竞争，结合PROCESSLIST能追溯到具体连接会话。常见事务状态包括RUNNING（正常执行）、LOCK WAIT（等待锁）、ROLLING BACK（回滚中）和COMMITTING（提交中），其中LOCK WAIT常指示性能瓶颈。监控长事务可通过查询INNODB_TRX中运行时间超阈值的记录；死锁则通过SHOW ENGINE INNODB STATUS中的LATEST DETECTED DEADLOCK部分或错误日志发现，并结合锁视图分析成因。诊断时还需关注SQL效率、索引使用、隔离级别（如REPEATABLE READ引入间隙锁）、回滚段占用及硬件资源等因素，综合判断性能问题根源。

MySQL中查看事务当前状态，最直接且有效的方式是结合SHOW ENGINE INNODB STATUS命令和information_schema数据库中的相关视图。前者能提供InnoDB存储引擎的宏观运行状态，包括活跃事务、锁等待等信息，而后者则能让你深入到每个具体会话的事务详情，比如事务ID、状态、开始时间以及正在执行的SQL语句。

解决方案

要了解MySQL事务的当前状态，我们通常会用到以下几个工具和命令：

1. SHOW ENGINE INNODB STATUS: 这是InnoDB存储引擎的“诊断报告”。执行这个命令后，你会看到一大段输出，我们需要关注其中的TRANSACTIONS部分。

   • 在TRANSACTIONS部分，你可以找到当前活跃的事务数量（ACTIVE_TRANSACTIONS）、最近一次被检测到的死锁（LATEST DETECTED DEADLOCK），以及一些正在运行的事务的详细信息，比如它们的状态（RUNNING、LOCK WAIT）、事务ID、以及它们正在执行的SQL语句。说实话，这部分信息比较原始，需要一点经验去解读，但它包含了非常关键的上下文。
   • 举个例子，如果看到LOCK WAIT，那说明有事务被阻塞了，很可能就是性能瓶颈所在。它会告诉你哪个事务在等待，等待哪个锁，以及等待的SQL是什么。

2. information_schema0: 这是直接查询InnoDB存储引擎中所有活跃事务的视图。它提供了比SHOW ENGINE INNODB STATUS更结构化、更容易解析的数据。

   • 你可以通过information_schema2来查看。
   • 这里面有几个字段特别有用：
     • information_schema3: 事务的唯一ID。
     • information_schema4: 事务的当前状态，比如RUNNING（正在运行）、LOCK WAIT（正在等待锁）、information_schema7（正在回滚）等。
     • information_schema8: 事务开始的时间。这对于发现长时间运行的事务非常关键。
     • information_schema9: 关联到MySQL的连接线程ID，可以结合SHOW ENGINE INNODB STATUS0来查找是哪个客户端连接。
     • SHOW ENGINE INNODB STATUS1: 事务当前正在执行的SQL语句。
   • 我个人经验来看，这个表是诊断事务问题时最常用的起点。

3. SHOW ENGINE INNODB STATUS0: 这个视图显示了所有当前连接到MySQL服务器的客户端进程。虽然它本身不直接显示事务状态，但它与SHOW ENGINE INNODB STATUS3结合使用时非常强大。

   • 通过SHOW ENGINE INNODB STATUS4，你可以看到每个连接的线程ID（SHOW ENGINE INNODB STATUS5）、用户、主机、正在执行的命令（SHOW ENGINE INNODB STATUS6，如SHOW ENGINE INNODB STATUS7、SHOW ENGINE INNODB STATUS8）、持续时间（SHOW ENGINE INNODB STATUS9）、状态（TRANSACTIONS0）以及正在执行的SQL语句（TRANSACTIONS1）。
   • 将TRANSACTIONS2与TRANSACTIONS3关联起来，你就能清楚地知道是哪个用户、从哪个IP发起的事务，以及它正在做什么。

4. TRANSACTIONS4 和 TRANSACTIONS5: 这两个视图专门用于查看InnoDB的锁信息。

   • TRANSACTIONS6显示了当前被持有或正在请求的所有锁。
   • TRANSACTIONS7则明确指出了哪些事务在等待哪些锁，以及是哪个事务持有了这些锁。
   • 当TRANSACTIONS8显示为LOCK WAIT时，这两个表就是你进一步分析锁竞争的利器。通过它们，你可以找到阻塞者（TRANSACTIONS0）和被阻塞者（TRANSACTIONS1）。

MySQL事务状态有哪些，它们意味着什么？

当我们谈论MySQL事务状态时，主要指的是information_schema0视图中information_schema4字段的值。理解这些状态对于诊断和优化数据库性能至关重要。

• RUNNING: 这是最常见的状态，表示事务正在正常执行中。它可能正在执行SQL语句，或者在等待客户端发送下一条SQL。如果一个事务长时间处于RUNNING状态，但SHOW ENGINE INNODB STATUS1为空，那可能意味着客户端正在思考人生，或者应用程序逻辑有问题，没有及时提交或回滚。
• LOCK WAIT: 这个状态表明事务正在等待一个或多个锁被释放。这通常是并发环境下最让人头疼的问题之一。事务可能在等待行锁、表锁，甚至是元数据锁。长时间的LOCK WAIT会导致系统吞吐量下降，甚至可能引发死锁。当你看到这个状态时，第一反应就应该是去查TRANSACTIONS7和TRANSACTIONS6，找出谁持有了锁，以及为什么不释放。
• information_schema7: 当事务被显式地ACTIVE_TRANSACTIONS2，或者因为某些错误（比如客户端断开连接、死锁被检测到并选择牺牲某个事务）而自动回滚时，就会进入这个状态。回滚操作本身也需要时间，特别是对于修改了大量数据的长事务，回滚过程可能会非常耗时，并占用大量的I/O和CPU资源。
• ACTIVE_TRANSACTIONS3: 事务在执行ACTIVE_TRANSACTIONS4操作时会短暂进入这个状态。这是一个非常快速的过程，通常不会长时间停留。如果一个事务长时间处于ACTIVE_TRANSACTIONS3状态，那可能预示着I/O系统压力大，或者有其他内部问题。

除了这些，我们还要留意ACTIVE_TRANSACTIONS6，它定义了事务之间的隔离程度，比如ACTIVE_TRANSACTIONS7（InnoDB默认）或ACTIVE_TRANSACTIONS8。不同的隔离级别会直接影响事务的锁行为和并发性能。

如何实时监控MySQL长事务与死锁？

实时监控长事务和死锁是数据库运维中的核心任务，因为它们是导致数据库性能下降、甚至系统崩溃的常见元凶。

监控长事务：

长事务是指执行时间过长的事务。它们会占用大量资源（如回滚段空间），可能持有锁太久，阻塞其他事务，从而严重影响并发性。

1. 基于information_schema0的查询: 这是最直接的方法。我们可以通过比较information_schema8和当前时间来找出那些运行时间超过阈值的事务。

   SELECT     trx_id,     trx_state,     trx_started,     trx_mysql_thread_id,     trx_query,     TIMESTAMPDIFF(SECOND, trx_started, NOW()) AS duration_seconds FROM     information_schema.INNODB_TRX WHERE     trx_state = 'RUNNING' AND TIMESTAMPDIFF(SECOND, trx_started, NOW()) > 60; -- 查找运行超过60秒的事务

   你可以把这个查询集成到你的监控系统中，定时执行，一旦发现有事务超过预设阈值，就触发告警。我通常会设置一个比较保守的阈值，比如30秒或60秒，然后根据业务特点再调整。

2. SHOW ENGINE INNODB STATUS输出分析: 虽然不如SHOW ENGINE INNODB STATUS3结构化，但它的TRANSACTIONS部分也会列出一些活跃事务。你可以通过脚本定时抓取其输出，然后解析其中的时间戳和SQL语句，识别长时间运行的事务。

监控死锁：

麦当秀MindShow AiPPT

麦当秀｜MINDSHOW是一款百万用户正在使用的三分钟生成一份PPT的AI应用系统。它利用引领前沿的人工智能技术，能够自动完成演示内容的设计。

224

查看详情

死锁是两个或多个事务互相持有对方需要的锁，导致所有事务都无法继续执行的僵局。InnoDB有内置的死锁检测机制，一旦检测到死锁，它会选择牺牲其中一个事务（回滚它），让另一个事务继续执行。

1. SHOW ENGINE INNODB STATUS的LATEST DETECTED DEADLOCK: 这是查看死锁信息的首选。当死锁发生时，InnoDB会将详细信息记录在这个区域。

   • 它会告诉你哪个事务是“受害者”（LATEST DETECTED DEADLOCK6），哪个事务是“持有者”（LATEST DETECTED DEADLOCK7）。
   • 还会列出它们各自持有的锁、请求的锁，以及导致死锁的SQL语句。
   • 我通常会定期检查这个输出，如果发现有死锁记录，就会立即分析SQL语句和业务逻辑，找出死锁原因并优化。

2. MySQL错误日志: 死锁信息也会被写入MySQL的错误日志（LATEST DETECTED DEADLOCK8）中。通过监控错误日志，可以及时发现死锁事件。这对于自动化告警来说非常重要。

3. TRANSACTIONS5和TRANSACTIONS6: 虽然它们不能直接告诉你死锁发生了，但可以帮助你识别严重的锁等待，这往往是死锁的前兆。

   SELECT     r.trx_id AS waiting_trx_id,     r.trx_mysql_thread_id AS waiting_thread,     r.trx_query AS waiting_query,     b.trx_id AS blocking_trx_id,     b.trx_mysql_thread_id AS blocking_thread,     b.trx_query AS blocking_query FROM     information_schema.INNODB_LOCK_WAITS lw JOIN     information_schema.INNODB_TRX r ON lw.requesting_trx_id = r.trx_id JOIN     information_schema.INNODB_TRX b ON lw.blocking_trx_id = b.trx_id;

   这个查询可以帮你看到“谁在等谁”，如果形成一个环，那死锁就不可避免了。

诊断事务性能问题时，除了状态我们还需要关注什么？

仅仅知道事务的状态是不够的，要全面诊断事务性能问题，我们还需要深入挖掘更多维度的数据和背景信息。

1. SQL语句本身的效率: 事务中执行的SQL语句是性能瓶颈的核心。

   • 索引使用: 检查SHOW ENGINE INNODB STATUS1中涉及的表是否都有合适的索引，是否发生了全表扫描（RUNNING2是你的好朋友）。
   • 复杂查询: 复杂的JOIN、子查询、排序或聚合操作，都可能导致性能下降。
   • WHERE条件: WHERE子句是否能有效利用索引？
   • 写入操作: RUNNING3/RUNNING4/RUNNING5语句是否一次性操作了大量数据？这会增加回滚段的负担和锁的粒度。

2. 锁的类型和粒度: InnoDB默认使用行级锁，这大大提高了并发性。但即使是行锁，如果设计不当，也可能导致严重的性能问题。

   • 锁升级: 某些情况下，InnoDB可能会将行锁升级为表锁，这会极大地限制并发。
   • 隐式锁: 例如，RUNNING6会显式加锁，但RUNNING4语句也会在更新的行上加锁。
   • 间隙锁（Gap Lock）: 在ACTIVE_TRANSACTIONS7隔离级别下，范围查询可能会加上间隙锁，锁定索引范围内的“空隙”，防止幻读，但也可能意外地阻塞其他事务。理解这些锁的行为至关重要。

3. 事务隔离级别: MySQL的默认隔离级别是ACTIVE_TRANSACTIONS7，它能有效防止幻读，但代价是可能引入更多的锁（如间隙锁）。如果你的业务对数据一致性要求不是那么高，或者并发冲突严重，可以考虑将隔离级别调整为ACTIVE_TRANSACTIONS8，它能减少间隙锁，提高并发性，但可能会引入幻读。这是一个权衡，没有银弹。

4. 回滚段（Undo Log）: 长事务会产生大量的回滚日志，存储在回滚段中。

   • 回滚段大小: 可以在SHOW ENGINE INNODB STATUS中查看LOCK WAIT2部分，了解回滚段的使用情况。如果回滚段过大，不仅占用磁盘空间，还会增加回滚操作的时间。
   • 清理: 回滚段需要被定期清理，长事务会阻碍清理进程，导致回滚段膨胀。

5. 硬件资源与系统配置:

   • IOPS: 如果事务涉及大量磁盘读写，而磁盘I/O性能不足，那事务处理速度必然受限。
   • CPU: 复杂的SQL计算、大量的锁管理都会消耗CPU。
   • 内存: LOCK WAIT3设置是否合理？它直接影响数据和索引的缓存效率。
   • LOCK WAIT4: 这个参数对事务提交的性能和数据安全性有巨大影响。设置为1最安全但性能最低，设置为0或2则性能更高但可能丢失少量数据。

6. 应用程序逻辑: 很多时候，数据库问题根源在于应用程序的设计。

   • 事务过大: 一个事务中包含了过多的操作，导致事务持续时间长，持有锁时间久。
   • 事务嵌套: 复杂的事务嵌套可能导致意想不到的锁行为。
   • 提交/回滚时机: 事务是否在必要时才提交？是否能及时释放资源？
   • 连接池配置: 连接池过小或过大都可能影响性能。

综合这些因素进行分析，才能更全面、更准确地定位和解决MySQL事务的性能问题。