MySQL作为常用的关系型数据库，在高并发业务场景下经常会出现并发写入冲突问题，这类问题通常表现为写入操作超时、数据更新不符合预期、死锁报错等，需要结合数据库的运行状态和日志信息逐步定位原因。
常见的并发写入冲突表现
并发写入冲突出现时通常会有以下几种典型表现，开发者可以先根据表现初步判断问题类型：
- 写入操作执行时间突然变长，甚至超过设置的超时时间直接报错
- 执行更新语句后，数据没有按照预期被修改，或者修改后的值和预期不符
- 错误日志中出现死锁相关的报错信息，提示事务被回滚
- 业务层面出现重复数据，或者计数类字段的数值和实际操作次数不一致
第一步：查看当前事务和锁信息
当发现疑似并发写入冲突时，首先可以查看当前数据库中的活跃事务和锁持有情况，定位是否有事务长时间持有锁导致其他写入操作阻塞。
查看活跃事务
可以通过查询information_schema库下的INNODB_TRX表获取当前正在执行的事务信息，包括事务开始时间、执行的SQL语句等：
-- 查询当前所有活跃的InnoDB事务 SELECT trx_id, trx_state, trx_started, trx_mysql_thread_id, trx_query FROM information_schema.INNODB_TRX;
如果发现有事务的trx_started时间很早，且trx_state为RUNNING，说明该事务可能长时间未提交，占用了对应的锁资源。
查看锁等待情况
通过查询INNODB_LOCK_WAITS表可以查看当前正在发生的锁等待关系，明确阻塞方和被阻塞方：
-- 查询锁等待关系
SELECT
waiting_trx_id, -- 等待锁的事务ID
waiting_pid, -- 等待锁的线程ID
blocking_trx_id, -- 持有锁的事务ID
blocking_pid -- 持有锁的线程ID
FROM information_schema.INNODB_LOCK_WAITS;
拿到阻塞方的线程ID后，可以通过SHOW PROCESSLIST命令查看该线程正在执行的SQL，进一步确认锁持有的原因。
第二步：分析事务隔离级别和锁机制
并发写入冲突和MySQL的事务隔离级别、锁机制密切相关，需要先确认当前实例的隔离级别，再结合业务SQL判断锁的加锁逻辑是否符合预期。
查看事务隔离级别
可以通过以下命令查看当前会话和全局的事务隔离级别：
-- 查看当前会话的事务隔离级别 SELECT @@transaction_isolation; -- 查看全局的事务隔离级别 SELECT @@global.transaction_isolation;
MySQL默认的事务隔离级别是REPEATABLE READ，在这个隔离级别下，普通的UPDATE、DELETE语句会对扫描到的行加行锁，如果扫描范围过大，可能会锁住多余的行，增加冲突概率。
确认SQL的加锁范围
可以通过EXPLAIN命令分析写入语句的执行计划，确认语句扫描的行范围，避免因为索引缺失导致全表扫描加锁的情况：
-- 分析更新语句的执行计划，确认是否使用索引 EXPLAIN UPDATE user_table SET score = score + 1 WHERE user_id = 1001;
如果执行计划中的type为ALL，说明语句进行了全表扫描，会对全表行加锁，极大概率引发并发写入冲突，此时需要为WHERE条件的字段添加合适的索引。
第三步：通过binlog日志回溯冲突过程
如果冲突已经发生，需要回溯当时的写入操作顺序，可以通过解析binlog日志来还原所有写入操作的执行顺序和内容。
开启binlog并查看日志文件
首先确认数据库是否开启了binlog，以及当前的binlog文件列表：
-- 查看binlog是否开启 SHOW VARIABLES LIKE 'log_bin'; -- 查看当前binlog文件列表 SHOW BINARY LOGS;
解析binlog内容
可以使用MySQL自带的mysqlbinlog工具解析指定的binlog文件，查看对应时间段的写入操作：
# 解析指定binlog文件中某个时间段的写入操作，输出为SQL格式 mysqlbinlog --start-datetime="2024-05-01 10:00:00" --stop-datetime="2024-05-01 10:30:00" --base64-output=DECODE-ROWS -v /var/lib/mysql/binlog.000012 > binlog_parse.sql
解析后的日志可以看到每个事务的开始、提交时间，以及具体的写入SQL内容，通过对比多个并发事务的操作顺序，就能找到冲突发生的具体逻辑。
常见冲突场景及解决方法
| 冲突场景 | 解决方法 |
|---|---|
| 长事务持有锁导致后续写入阻塞 | 优化事务逻辑，尽量缩短事务执行时间，避免事务中执行耗时操作，及时提交或回滚事务 |
| 无索引导致写入语句锁全表 | 为写入语句的WHERE条件字段添加合适的索引，减少锁的覆盖范围 |
| 多事务更新同一行数据引发死锁 | 统一多个事务更新数据的顺序，避免交叉加锁；或者降低事务隔离级别为READ COMMITTED |
| 并发插入唯一键冲突 | 插入前先查询是否存在，或者使用INSERT ... ON DUPLICATE KEY UPDATE语法处理重复场景 |
长期优化建议
除了临时排查解决冲突，还可以通过以下方式减少并发写入冲突的发生概率：
- 合理设计索引，避免写入语句出现全表扫描的情况
- 尽量将大事务拆分成多个小事务，减少锁的持有时间
- 如果业务允许，可以适当降低事务隔离级别，减少间隙锁的使用
- 对热点写入行，可以考虑在业务层增加缓存或者分散写入压力，避免集中更新同一行数据