SQL事务提交慢需从日志写入和锁等待切入：检查InnoDB日志刷盘滞后、磁盘I/O饱和及innodb_flush_log_at_trx_commit设置；通过performance_schema定位锁等待链与阻塞源头；结合通用日志与慢日志分析COMMIT耗时及锁等待占比。
SQL事务提交慢，通常不是单一原因导致，而是日志写入、锁竞争、磁盘I/O、事务设计等多环节协同作用的结果。排查需从数据库日志和锁等待两个核心维度切入，快速定位瓶颈点。
检查事务日志写入是否成为瓶颈
事务提交（COMMIT）必须等待redo日志落盘（默认sync模式），若日志写入慢，所有提交都会被拖慢。重点关注：
-
查看InnoDB日志相关状态：执行SHOW ENGINE INNODB STATUS\G，观察LOG部分中的
Log sequence number与Log flushed up to差值——若持续偏大（如超百MB），说明刷日志滞后； -
检查磁盘I/O能力：用iostat -x 1观察
%util和await，尤其关注存储redo日志的设备（如/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_TRX\G，重点关注
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推进速度判断。
补充建议：快速收敛排查路径
不要一上来就翻源码或调参，按顺序做这三步往往见效最快：
- 用pt-deadlock-logger实时捕获死锁与长等待（Percona Toolkit工具）；
- 对疑似慢提交事务，在应用侧加打点，记录BEGIN到COMMIT耗时，并同步记录SQL原文与参数；
- 在数据库端用SELECT THREAD_ID, EVENT_NAME, TIMER_WAIT FROM performance_schema.events_statements_history_long WHERE SQL_TEXT LIKE '%COMMIT%' ORDER BY TIMER_WAIT DESC LIMIT 5;直接抓最慢的5次提交事件。
