为何WHERE id=<主键>的简单UPDATE操作会引发锁等待？

以下是针对你遇到的问题——150个Worker并发更新单表主键行时出现锁等待超时、重启容器后15分钟恢复正常——的具体排查方向：

• 事务未及时提交/长事务堆积
  检查Worker端的代码逻辑：是否存在执行UPDATE后未立即COMMIT的情况？或者事务包裹了非数据库操作（比如调用外部接口、本地文件读写），导致事务持锁时间被大幅拉长。
  可以通过SHOW ENGINE INNODB STATUS;查看当前活跃事务详情，或关联performance_schema.data_lock_waits与information_schema.processlist，定位持锁事务的执行状态和当前运行语句。重启后初期正常、后续出问题，大概率是未提交事务随时间堆积引发的锁竞争。

• Docker容器资源限制
  确认Docker容器是否被限制了CPU/内存配额：如果CPU核数或内存分配不足，150个并发请求过来时MySQL进程无法及时获得调度资源，导致事务执行缓慢、锁无法及时释放。用docker stats实时查看容器的CPU使用率、内存占用，对比宿主机的剩余资源情况。
  另外检查Hetzner实例的存储类型：若使用云盘，高峰时的IO延迟可能被iostat的平均数值掩盖，可通过SHOW GLOBAL STATUS LIKE 'InnoDB%io%';查看InnoDB_log_write_waits等指标，确认是否存在IO等待瓶颈。

• InnoDB事务日志配置瓶颈
  当大量并发更新时，redo log刷写可能成为性能瓶颈：

  • 检查innodb_flush_log_at_trx_commit设置：若为1，每次事务提交都会强制刷写redo log到磁盘，高并发下会显著增加IO压力；若业务允许少量数据丢失，可临时改为2（每秒刷写一次）测试是否缓解问题。
  • 确认innodb_log_file_size是否过小：过小的日志文件会导致频繁触发checkpoint，拖慢事务执行速度。通过SHOW ENGINE INNODB STATUS;查看日志序列号与刷写位置的差距，判断日志文件是否足够。

• 锁范围异常或表锁干扰
  虽然是主键单条更新，但仍需确认：

  • 表的主键是否为离散值（如UUID）？离散主键可能引发聚簇索引页分裂，导致更新时持有额外的邻键锁。可通过performance_schema.data_locks查看锁的类型（LOCK_MODE字段），确认是否为行锁（X,REC_NOT_GAP）而非范围锁。
  • 是否存在后台执行的DDL语句（如ALTER TABLE）或显式锁表操作？这类操作会持有表锁，阻塞所有更新请求，可通过SHOW PROCESSLIST;排查是否有长期运行的DDL进程。

• 统计信息过期导致执行计划异常
  若表的统计信息过期，MySQL可能选择低效的执行路径（尽管主键更新理论上会走索引）。用EXPLAIN UPDATE arb.cross_exchange_current_orders_snapshot SET ... WHERE id = 9101;查看执行计划，确认是否为const类型的直接行访问。若不是，执行ANALYZE TABLE arb.cross_exchange_current_orders_snapshot;更新统计信息后再测试。

• 线程池/连接池配置问题
  检查MySQL的max_connections是否足够容纳150个并发请求，避免因连接排队间接拉长事务持锁时间。若开启了线程池（thread_pool），确认thread_pool_size配置是否合理，过低的线程数会导致请求无法及时被处理。

内容的提问来源于stack exchange，提问作者user2515194