答案：监控mysql事务冲突需结合隔离级别与锁机制，通过慢查询日志、performance_schema、死锁日志及INNODB_TRX表分析锁等待、阻塞与未提交事务，定期巡检并建立常态化监控机制以提前发现风险。
在 MySQL 中监控事务冲突，关键在于理解事务隔离级别、锁机制以及利用系统工具和日志来捕捉异常行为。事务冲突通常表现为锁等待、死锁或并发更新失败，直接影响应用性能和数据一致性。通过合理配置和主动监控，可以及时发现并解决问题。
启用并分析慢查询日志
慢查询日志是定位事务问题的第一道防线。长时间运行的事务可能持有锁过久，导致其他事务阻塞。
- 确保 slow_query_log = ON 并设置合理的 long_query_time（如1秒）
- 关注执行时间长且涉及多行更新的事务
- 使用 mysqldumpslow 或 pt-query-digest 分析日志，找出频繁出现的锁定操作
查看锁等待与阻塞情况
MySQL 提供了 performance_schema 和 information_schema 中的表来实时查看锁状态。
- 查询 performance_schema.data_lock_waits 表获取当前的锁等待信息
- 结合 data_locks 和 threads 表定位哪个会话被阻塞、谁在持有锁
- 使用如下语句快速检查：
select * FROM performance_schema.data_lock_waitsG
输出中重点关注 REQUESTING_ENGINE_TRANSACTION_ID 和 BLOCKING_ENGINE_TRANSACTION_ID，可追溯到具体连接和SQL。
捕获并分析死锁日志
死锁是事务冲突的极端表现，MySQL 自动检测并回滚其中一个事务。但需要主动查看日志才能了解原因。
- 确保 innodb_print_all_deadlocks 开启，将每次死锁记录到错误日志
- 在错误日志中搜索 “LATEST DETECTED DEADLOCK” 段落
- 分析死锁日志中的事务顺序、持有的锁和等待的资源，判断是否索引缺失或事务逻辑不合理
常见模式：两个事务以相反顺序更新相同记录，形成循环等待。
监控未提交事务与时长
长时间未提交的事务会累积锁资源，增加冲突概率。
- 查询 information_schema.INNODB_TRX 查看当前运行的事务
- 关注 trx_state 为 RUNNING 且 trx_started 时间过早的记录
- 结合 PROCEsslIST 找出对应连接，必要时手动终止（KILL CONNECTION）
定期巡检该表，能有效预防因应用异常导致的事务悬挂问题。
基本上就这些。通过日志、系统表和性能视图的组合使用，可以全面掌握 MySQL 中的事务冲突情况。重点不是等出问题再查，而是建立常态化监控机制，提前发现潜在风险。