事务过长导致锁等待飙升，需收缩事务边界、避免外部调用与同步日志，update/delete须带精确where条件，索引要覆盖查询且符合最左前缀，禁用函数操作破坏索引。
事务太长导致锁等待飙升，怎么砍？
高并发下事务慢，90%不是SQL本身慢，而是事务边界划得太宽——比如HTTP请求一进来就开事务，中间调三次外部API、写两次日志，最后才UPDATE数据库。锁从一开始就被占着，别人只能排队。
- 查真实锁压力：
Innodb_row_lock_waits每秒涨几十次，先别急着加索引，用SELECT * FROM information_schema.INNODB_TRX ORDER BY TRX_STARTED LIMIT 5找出运行超2秒的事务，重点看TRX_QUERY和TRX_STATE - 事务里禁做三件事：HTTP调用、文件读写、日志落盘（尤其是同步写）
-
UPDATE/DELETE必须带精确WHERE条件，严禁UPDATE t SET status=1这种无条件全表更新
行锁争用严重，是不是索引没建对？
热点行更新（比如秒杀扣库存）卡住，往往不是锁机制问题，而是索引没覆盖查询条件，导致行锁升级成表锁或锁范围过大。
- 执行
EXPLAIN SELECT ... FOR UPDATE，确认是否走了索引；如果type是ALL或index，说明扫描了整张表或整棵索引树，锁会覆盖所有扫描行 - 复合索引要严格遵循最左前缀：查询条件含
user_id和status，但索引是(status, user_id)，那WHERE user_id = ?就用不上 - 避免在索引字段上做函数操作：
WHERE DATE(create_time) = '2026-08-11'会失效，改用WHERE create_time >= '2026-08-11 00:00:00' AND create_time
并发写入QPS上不去，是不是事务日志拖累了？
每笔事务都要写redo log、undo log、binlog，三重日志刷盘在高QPS下极易成为I/O瓶颈，尤其当innodb_log_file_size太小、频繁checkpoint时。
- 检查
SHOW GLOBAL STATUS LIKE 'Innodb_os_log_written'，如果每秒写入量长期接近innodb_log_file_size × 2，说明日志循环太快，需增大innodb_log_file_size（MySQL 8.0+建议设为1–2GB） -
sync_binlog设为1最安全，但会显著拖慢写入；若业务允许短暂主从延迟，可设为100或0（依赖操作系统刷盘） -
innodb_flush_log_at_trx_commit：设为1保证ACID，设为2可大幅提升吞吐（崩溃可能丢1秒事务），设为0仅适合日志类非关键数据
连接数爆满还查不到真凶？盯紧Threads_running
SHOW PROCESSLIST里全是Sleep状态，不代表没事——真正干活的线程数藏在Threads_running里。它才是并发压力的硬指标。
- 执行
SHOW GLOBAL STATUS LIKE 'Threads_running'，持续≥32就要警惕，≥64基本说明CPU或锁已打满 - 对比
Threads_connected：如果后者远大于前者，说明应用层连接没释放（比如Java没调Connection.close()） -
max_connections设得再大也没用，如果Threads_running长期卡在10–20，大概率是某条慢SQL或长事务堵住了队列头
事务优化不是调几个参数就能解决的事——锁粒度、日志刷盘节奏、连接生命周期，每个环节都可能成为隐性瓶颈。最容易被忽略的是事务与外部依赖的耦合，比如在事务里等一个HTTP响应，这个等待时间全算在锁持有时间内。
