MySQL中查看事务当前状态，最直接且有效的方式是结合
SHOW ENGINE INNODB STATUS命令和
information_schema数据库中的相关视图。前者能提供InnoDB存储引擎的宏观运行状态，包括活跃事务、锁等待等信息，而后者则能让你深入到每个具体会话的事务详情，比如事务ID、状态、开始时间以及正在执行的SQL语句。
解决方案
要了解MySQL事务的当前状态，我们通常会用到以下几个工具和命令：
SHOW ENGINE INNODB STATUS
: 这是InnoDB存储引擎的“诊断报告”。执行这个命令后，你会看到一大段输出，我们需要关注其中的
TRANSACTIONS部分。 在
TRANSACTIONS部分，你可以找到当前活跃的事务数量（
ACTIVE_TRANSACTIONS）、最近一次被检测到的死锁（
LATEST DETECTED DEADLOCK），以及一些正在运行的事务的详细信息，比如它们的状态（
RUNNING、
LOCK WAIT）、事务ID、以及它们正在执行的SQL语句。说实话，这部分信息比较原始，需要一点经验去解读，但它包含了非常关键的上下文。 举个例子，如果看到
LOCK WAIT，那说明有事务被阻塞了，很可能就是性能瓶颈所在。它会告诉你哪个事务在等待，等待哪个锁，以及等待的SQL是什么。
information_schema.INNODB_TRX
: 这是直接查询InnoDB存储引擎中所有活跃事务的视图。它提供了比
SHOW ENGINE INNODB STATUS更结构化、更容易解析的数据。 你可以通过
SELECT * FROM information_schema.INNODB_TRX;来查看。 这里面有几个字段特别有用：
trx_id: 事务的唯一ID。
trx_state: 事务的当前状态，比如
RUNNING（正在运行）、
LOCK WAIT（正在等待锁）、
ROLLING BACK（正在回滚）等。
trx_started: 事务开始的时间。这对于发现长时间运行的事务非常关键。
trx_mysql_thread_id: 关联到MySQL的连接线程ID，可以结合
information_schema.PROCESSLIST来查找是哪个客户端连接。
trx_query: 事务当前正在执行的SQL语句。 我个人经验来看，这个表是诊断事务问题时最常用的起点。
information_schema.PROCESSLIST
: 这个视图显示了所有当前连接到MySQL服务器的客户端进程。虽然它本身不直接显示事务状态，但它与
INNODB_TRX结合使用时非常强大。 通过
SELECT id, user, host, db, command, time, state, info FROM information_schema.PROCESSLIST;，你可以看到每个连接的线程ID（
id）、用户、主机、正在执行的命令（
command，如
Query、
Sleep）、持续时间（
time）、状态（
state）以及正在执行的SQL语句（
info）。 将
INNODB_TRX.trx_mysql_thread_id与
PROCESSLIST.id关联起来，你就能清楚地知道是哪个用户、从哪个IP发起的事务，以及它正在做什么。
information_schema.INNODB_LOCKS
和 information_schema.INNODB_LOCK_WAITS
: 这两个视图专门用于查看InnoDB的锁信息。
INNODB_LOCKS显示了当前被持有或正在请求的所有锁。
INNODB_LOCK_WAITS则明确指出了哪些事务在等待哪些锁，以及是哪个事务持有了这些锁。 当
INNODB_TRX.trx_state显示为
LOCK WAIT时，这两个表就是你进一步分析锁竞争的利器。通过它们，你可以找到阻塞者（
requesting_trx_id）和被阻塞者（
blocking_trx_id）。
MySQL事务状态有哪些，它们意味着什么？
当我们谈论MySQL事务状态时，主要指的是
information_schema.INNODB_TRX视图中
trx_state字段的值。理解这些状态对于诊断和优化数据库性能至关重要。
RUNNING: 这是最常见的状态，表示事务正在正常执行中。它可能正在执行SQL语句，或者在等待客户端发送下一条SQL。如果一个事务长时间处于
RUNNING状态，但
trx_query为空，那可能意味着客户端正在思考人生，或者应用程序逻辑有问题，没有及时提交或回滚。
LOCK WAIT: 这个状态表明事务正在等待一个或多个锁被释放。这通常是并发环境下最让人头疼的问题之一。事务可能在等待行锁、表锁，甚至是元数据锁。长时间的
LOCK WAIT会导致系统吞吐量下降，甚至可能引发死锁。当你看到这个状态时，第一反应就应该是去查
INNODB_LOCK_WAITS和
INNODB_LOCKS，找出谁持有了锁，以及为什么不释放。
ROLLING BACK: 当事务被显式地
ROLLBACK，或者因为某些错误（比如客户端断开连接、死锁被检测到并选择牺牲某个事务）而自动回滚时，就会进入这个状态。回滚操作本身也需要时间，特别是对于修改了大量数据的长事务，回滚过程可能会非常耗时，并占用大量的I/O和CPU资源。
COMMITTING: 事务在执行
COMMIT操作时会短暂进入这个状态。这是一个非常快速的过程，通常不会长时间停留。如果一个事务长时间处于
COMMITTING状态，那可能预示着I/O系统压力大，或者有其他内部问题。
除了这些，我们还要留意
trx_isolation_level，它定义了事务之间的隔离程度，比如
REPEATABLE READ（InnoDB默认）或
READ COMMITTED。不同的隔离级别会直接影响事务的锁行为和并发性能。
如何实时监控MySQL长事务与死锁？
实时监控长事务和死锁是数据库运维中的核心任务，因为它们是导致数据库性能下降、甚至系统崩溃的常见元凶。
监控长事务：
长事务是指执行时间过长的事务。它们会占用大量资源（如回滚段空间），可能持有锁太久，阻塞其他事务，从而严重影响并发性。
基于information_schema.INNODB_TRX
的查询: 这是最直接的方法。我们可以通过比较
trx_started和当前时间来找出那些运行时间超过阈值的事务。
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秒，然后根据业务特点再调整。
SHOW ENGINE INNODB STATUS
输出分析: 虽然不如
INNODB_TRX结构化，但它的
TRANSACTIONS部分也会列出一些活跃事务。你可以通过脚本定时抓取其输出，然后解析其中的时间戳和SQL语句，识别长时间运行的事务。
监控死锁：
死锁是两个或多个事务互相持有对方需要的锁，导致所有事务都无法继续执行的僵局。InnoDB有内置的死锁检测机制，一旦检测到死锁，它会选择牺牲其中一个事务（回滚它），让另一个事务继续执行。
SHOW ENGINE INNODB STATUS
的LATEST DETECTED DEADLOCK
: 这是查看死锁信息的首选。当死锁发生时，InnoDB会将详细信息记录在这个区域。
TRANSACTION (1) ... was TRX_ID ...），哪个事务是“持有者”（
TRANSACTION (2) ... was TRX_ID ...）。 还会列出它们各自持有的锁、请求的锁，以及导致死锁的SQL语句。 我通常会定期检查这个输出，如果发现有死锁记录，就会立即分析SQL语句和业务逻辑，找出死锁原因并优化。
MySQL错误日志: 死锁信息也会被写入MySQL的错误日志（
error.log）中。通过监控错误日志，可以及时发现死锁事件。这对于自动化告警来说非常重要。
information_schema.INNODB_LOCK_WAITS
和INNODB_LOCKS
: 虽然它们不能直接告诉你死锁发生了，但可以帮助你识别严重的锁等待，这往往是死锁的前兆。
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;这个查询可以帮你看到“谁在等谁”，如果形成一个环，那死锁就不可避免了。
诊断事务性能问题时，除了状态我们还需要关注什么？
仅仅知道事务的状态是不够的，要全面诊断事务性能问题，我们还需要深入挖掘更多维度的数据和背景信息。
SQL语句本身的效率: 事务中执行的SQL语句是性能瓶颈的核心。
索引使用: 检查trx_query中涉及的表是否都有合适的索引，是否发生了全表扫描（
EXPLAIN是你的好朋友）。 复杂查询: 复杂的JOIN、子查询、排序或聚合操作，都可能导致性能下降。 WHERE条件: WHERE子句是否能有效利用索引？ 写入操作:
INSERT/
UPDATE/
DELETE语句是否一次性操作了大量数据？这会增加回滚段的负担和锁的粒度。
锁的类型和粒度: InnoDB默认使用行级锁，这大大提高了并发性。但即使是行锁，如果设计不当，也可能导致严重的性能问题。
锁升级: 某些情况下，InnoDB可能会将行锁升级为表锁，这会极大地限制并发。 隐式锁: 例如，SELECT ... FOR UPDATE会显式加锁，但
UPDATE语句也会在更新的行上加锁。 间隙锁（Gap Lock）: 在
REPEATABLE READ隔离级别下，范围查询可能会加上间隙锁，锁定索引范围内的“空隙”，防止幻读，但也可能意外地阻塞其他事务。理解这些锁的行为至关重要。
事务隔离级别: MySQL的默认隔离级别是
REPEATABLE READ，它能有效防止幻读，但代价是可能引入更多的锁（如间隙锁）。如果你的业务对数据一致性要求不是那么高，或者并发冲突严重，可以考虑将隔离级别调整为
READ COMMITTED，它能减少间隙锁，提高并发性，但可能会引入幻读。这是一个权衡，没有银弹。
回滚段（Undo Log）: 长事务会产生大量的回滚日志，存储在回滚段中。
回滚段大小: 可以在SHOW ENGINE INNODB STATUS中查看
UNDO LOG部分，了解回滚段的使用情况。如果回滚段过大，不仅占用磁盘空间，还会增加回滚操作的时间。 清理: 回滚段需要被定期清理，长事务会阻碍清理进程，导致回滚段膨胀。
硬件资源与系统配置:
IOPS: 如果事务涉及大量磁盘读写，而磁盘I/O性能不足，那事务处理速度必然受限。 CPU: 复杂的SQL计算、大量的锁管理都会消耗CPU。 内存:innodb_buffer_pool_size设置是否合理？它直接影响数据和索引的缓存效率。
innodb_flush_log_at_trx_commit: 这个参数对事务提交的性能和数据安全性有巨大影响。设置为1最安全但性能最低，设置为0或2则性能更高但可能丢失少量数据。
应用程序逻辑: 很多时候，数据库问题根源在于应用程序的设计。
事务过大: 一个事务中包含了过多的操作，导致事务持续时间长，持有锁时间久。 事务嵌套: 复杂的事务嵌套可能导致意想不到的锁行为。 提交/回滚时机: 事务是否在必要时才提交？是否能及时释放资源？ 连接池配置: 连接池过小或过大都可能影响性能。综合这些因素进行分析，才能更全面、更准确地定位和解决MySQL事务的性能问题。
