sql事务提交慢需从日志写入和锁等待切入：检查 InnoDB 日志刷盘滞后、磁盘 I / O 饱和及 innodb_flush_log_at_trx_commit 设置；通过 performance_schema 定位锁等待链与阻塞源头；结合通用日志与慢日志分析 COMMIT 耗时及锁等待占比。
SQL 事务提交慢，通常不是单一原因导致，而是日志写入、锁竞争、磁盘 I /O、事务设计等多环节协同作用的结果。排查需从 数据库 日志和锁等待两个核心维度切入，快速定位瓶颈点。
检查事务日志写入是否成为瓶颈
事务提交（COMMIT）必须等待red o 日志落盘（默认 sync 模式），若日志写入慢，所有提交都会被拖慢。重点关注：
- 查看 InnoDB 日志相关状态 ：执行SHOW ENGINE INNODB STATUSG，观察LOG 部分中的
Log sequence number与Log flushed up to差值——若持续偏大（如超百 MB），说明刷日志滞后； - 检查磁盘 I / O 能力 ：用iostat -x 1 观察
%util和await，尤其关注存储 red o 日志的设备（如/var/lib/mysql/ib_logfile*所在磁盘）是否饱和； - 确认 innodb_flush_log_at_trx_commit 设置 ：值为 1（默认）最安全但性能最低；若业务允许短暂 数据丢失 风险，可临时调为 2（日志写 OS 缓存）或 0（每秒刷一次），但仅限排查验证，不可长期使用。
分析锁等待链路与阻塞源头
提交慢常因事务在等待行锁、间隙锁或元数据锁（MDL），而自身又持有其他锁，形成锁等待链。关键操作：
- 查当前阻塞关系 ：MySQL 5.7+ 执行select * FROM performance_schema.data_lock_waits;（需开启
performance_schema及data_locks、data_lock_waits采集）； - 看活跃事务与锁信息 ：运行SELECT * FROM information_schema.INNODB_TRXG，重点关注
TRX_STATE = 'LOCK WAIT'的事务，记下TRX_ID和TRX_MYSQL_THREAD_ID；再结合 SELECT * FROM information_schema.INNODB_LOCKS; 与SELECT * FROM information_schema.INNODB_LOCK_WAITS;定位谁在等谁、等哪条记录； - 注意隐式锁升级场景 ：长事务未提交、大范围 UPDATE/delete 未走索引、ORDER BY + LIMIT 配合 FOR UPDATE 等，都易引发大量行锁或间隙锁争用。
结合慢日志与通用日志交叉验证
启用并分析两类日志，能还原真实提交行为：
- 开启 general_log（临时）：设 SET GLOBAL general_log = ON;，配合general_log_file 定位具体哪条 COMMIT 语句耗时高（注意：仅限低峰期短时开启，避免 IO 冲击）；
- 解析 slow_query_log：确保 long_query_time = 0 并开启 log_slow_admin_statements，使 COMMIT 也计入慢日志；重点看
Rows_examined、Lock_time、Rows_sent字段，若Lock_time占比极高，基本锁定锁问题； - 检查 binlog 写入延迟（主库）：若启用了
sync_binlog=1且 binlog 与 redo 同盘，也可能叠加 I / O 压力，可通过 SHOW MASTER STATUS 对比File和position推进速度判断。
补充建议：快速收敛排查路径
不要一上来就翻源码或调参，按顺序做这三步往往见效最快：
