长事务导致行锁堆积，因InnoDB在事务未提交前持续持有X锁，阻塞其他事务更新同一行；常见于将耗时操作包入事务中，锁直到commit才释放。

长事务为什么会导致行锁堆积

事务开启后未提交，InnoDB 会一直持有已修改行的 X 锁（排他锁），其他事务想更新同一行就会卡在 Waiting for table metadata lock 或直接超时。常见于 PHP 中把耗时操作（如远程 API 调用、大循环计算、文件读写）包进 beginTransaction() 和 commit() 之间——锁不是等 SQL 执行完就释放，而是等到整个事务结束才释放。

怎么识别事务是否“过大”

看三类信号：

• MySQL 慢查询日志里出现带 SELECT ... FOR UPDATE 或 UPDATE 的语句，执行时间 > 1s
• 监控发现 Innodb_row_lock_time_avg 持续升高，或 SHOW ENGINE INNODB STATUS 输出中频繁出现 ---TRANSACTION ... WAITING FOR THIS LOCK TO BE GRANTED
• 用户反馈某接口偶发性卡顿或报错 Lock wait timeout exceeded

  拆分事务的实操边界在哪

  核心原则：只把「必须原子性保证」的操作留在事务内，其余全移出去。例如一个订单创建流程：

  • ✅ 必须在事务内：INSERT INTO orders、UPDATE products SET stock = stock - 1 WHERE id = ?（库存扣减需和订单强一致）
  • ❌ 必须移出事务：file_put_contents('log/order.log', ...)、curl_exec($notify_api)、generate_pdf()
  • ⚠️ 可选异步化：INSERT INTO order_logs（若允许日志延迟写入，可改用消息队列或定时任务补）

  拆分后结构示意：

  

  btpanel phpsite 宝塔面板PHP网站

  宝塔面板 PHP 网站管理：站点创建、删除、启停、PHP 版本切换、域名管理、SSL证书管理、伪静态管理、数据库管理

  下载

  try {
      $pdo->beginTransaction();
      $pdo->prepare("INSERT INTO orders (...) VALUES (...)")->execute([...]);
      $pdo->prepare("UPDATE products SET stock = stock - 1 WHERE id = ?")->execute([$pid]);
      $pdo->commit();
  <pre class="brush:php;toolbar:false;">// ✅ 事务已结束，锁已释放
  notify_order_created($order_id); // 远程通知
  write_order_log($order_id);      // 文件写入

  } catch (Exception $e) { $pdo->rollback(); throw $e; }

  拆分后还要防什么坑

  拆事务不等于万事大吉，下面三点最容易被忽略：

  • 业务幂等性没做：通知接口失败重试时，notify_order_created() 可能被调两次，得靠数据库唯一索引或 Redis SET order_notify_123 "done" NX PX 3600 拦住重复
  • 补偿逻辑缺失：事务成功但后续步骤失败（如通知超时），没有记录失败状态或触发重试队列，导致订单“半完成”
  • 分离后的数据一致性假象：比如库存扣减成功，但通知失败，用户以为下单失败而重复点击——前端要禁用按钮 + 后端查订单状态接口兜底

  真正的难点不在“怎么拆”，而在拆完之后，如何让各环节在失败时仍能收敛到一个确定状态。

php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！