首先通过INNODB_TRX表定位长时间运行的事务，再结合SHOW PROCESSLIST和data_lock_waits分析阻塞会话，接着利用Performance Schema监控锁事件，并启用innodb_print_all_deadlocks记录死锁信息，最后检查隔离级别与执行计划，优化应用逻辑以减少冲突。
MySQL 中事务冲突通常表现为锁等待、死锁或事务长时间阻塞，影响系统性能和响应速度。排查这类问题需结合数据库状态、日志信息和 SQL 执行情况综合分析。以下是常用的排查方法。
1. 查看当前正在运行的事务
通过 information_schema.INNODB_TRX 表可以查看当前所有活跃的 InnoDB 事务，帮助定位长时间未提交的事务。
执行语句：
SELECT * FROM information_schema.INNODB_TRX\G
重点关注以下字段：
- trx_id：事务 ID
- trx_state：事务状态（如 RUNNING、LOCK WAIT）
- trx_started：事务开始时间，若时间过长可能是未及时提交
- trx_mysql_thread_id：对应线程 ID，可用于关联 processlist
- trx_query：当前正在执行的 SQL
2. 检查线程和连接状态
使用 SHOW PROCESSLIST 查看当前数据库连接和执行中的语句。
命令：
SHOW FULL PROCESSLIST;
可识别出哪些连接处于 Locked 或长时间执行状态，结合 INNODB_TRX 可追踪到具体会话。
3. 分析锁等待与死锁日志
InnoDB 提供了详细的锁信息，可通过以下方式获取：
- 查看锁等待情况：
SELECT * FROM information_schema.INNODB_LOCKS;（MySQL 5.7 及以前）
注意：MySQL 8.0 已废弃该表，改用 performance_schema。 - 查看事务持有的锁：
SELECT * FROM performance_schema.data_locks;（MySQL 8.0+） - 查看锁等待关系：
SELECT * FROM performance_schema.data_lock_waits;
对于死锁，启用 innodb_print_all_deadlocks 将死锁信息记录到错误日志中。
配置项：
SET GLOBAL innodb_print_all_deadlocks = ON;
之后可在 MySQL 错误日志中查看完整的死锁详情，包括涉及的事务、SQL、锁类型和资源。
4. 使用 Performance Schema 深入分析
MySQL 5.6+ 提供了 Performance Schema，可监控事务行为和锁事件。
例如，查询最近的锁等待事件：
SELECT * FROM performance_schema.events_waits_current WHERE EVENT_NAME LIKE '%lock%';
也可结合 setup_instruments 和 setup_consumers 开启相关采集项。
5. 检查隔离级别与 SQL 执行计划
事务冲突常与隔离级别有关。查看当前会话或全局隔离级别：
SELECT @@transaction_isolation;
高隔离级别（如 REPEATABLE READ）更容易产生间隙锁，导致锁冲突。评估是否可降低为 READ COMMITTED。
同时检查冲突 SQL 的执行计划：
EXPLAIN FORMAT=JSON your_sql_statement;
确认是否走了索引，避免全表扫描引发大量行锁。
6. 应用层检查与优化建议
事务冲突往往源于应用逻辑问题：
- 事务过大，包含过多操作或耗时请求
- 未及时提交或回滚事务（如异常未捕获）
- 多个事务以不同顺序访问相同资源，易引发死锁
建议：
- 缩短事务范围，只包裹必要操作
- 加锁操作按固定顺序执行
- 设置合理超时：
innodb_lock_wait_timeout - 程序中捕获死锁异常（如 1213 错误），并实现重试机制
基本上就这些。通过组合使用系统表、性能视图和日志分析，能有效定位 MySQL 事务冲突根源。关键在及时发现长事务、理解锁行为，并优化应用逻辑与 SQL 设计。
