企业官网建设流程全解析

我一直觉得，PHP开发里最容易被低估的坑，就是“事务里面调用外部API”。很多人写业务代码，尤其是做订单、支付、积分这类功能，顺手就在数据库事务里塞了一个 HTTP 请求，比如调支付网关、给用户发通知、同步第三方库存。事务提交成功，你好我好；事务一回滚，问题就来了：外部那边的钱可能已经扣了，通知可能已经发了，数据库里却是“失败”的状态。说严重点，你在事务里调外部 API，等于把分布式系统的不确定性，强行塞进了一个本应隔离的数据库环境。

今天这篇就把这个事彻底拆开说清楚。内容围绕“PHP事务内禁止调用外部API”展开，但本质不限于 PHP，任何语言只要用到关系型数据库事务，这套道理都成立。我会从原理层面讲透为什么不能调，再给一套可以直接落地的替代方案，包括本地消息表（Outbox）、事务后置钩子、幂等消费，以及我在生产环境里踩过的锁等待、重复通知、状态失真这些坑。适合正在写订单支付、对账、库存同步之类的业务，或者刚接触事务但总感觉哪里不对劲的中级开发者。

1. 先摊开来说：你在事务里调外部API，实际做了一次豪赌

1.1 事务设计的教科书设定 vs 生产环境的真实诱惑

教科书对事务的定义很干净：ACID，原子性、一致性、隔离性、持久性。它假设你操作的所有资源都在同一个数据库里，要么全成功，要么全失败。可一旦你在事务中间发起一个 HTTP 请求，事情就变了。你操作的不再是单一的 MySQL，而是“MySQL + 某个外部黑盒”，这个黑盒有自己的网络延迟、自己的超时策略、自己的数据状态，而且完全不受你的事务控制。

生产环境里为什么总有同事这么干？因为方便。我见过不少代码，下单、锁库存、扣余额、调物流接口，全写在一个beginTransaction()到commit()里面。逻辑看起来一气呵成，如果物流接口返回失败，整个订单回滚，明面上“一致性”很强。但“方便”只是为开发期准备的，上线后的每一个小时都会为这个选择还债。

真实诱惑还有一种变体：直接在事务里查询外部接口，比如获取第三方服务商返回的某个标识，然后把标识写进数据库。代码里就一行同步调用，但数据库事务的锁会老老实实等你那个 HTTP 响应回来。你等多久，其他事务就等多久。

1.2 三个副作用逐项解构：锁、可见性与回滚黑洞

副作用一，锁时间被拉长。InnoDB 默认隔离级别是 Repeatable Read，你在事务里执行的 UPDATE、DELETE、INSERT 都会持有记录锁或间隙锁，直到提交或回滚才释放。外部 API 的响应时间通常从几十毫秒到几秒不等，如果上游慢，几十秒甚至超时也是常有的事。也就是说，你的行锁被一个网络请求按住不放，其他更新同一行的事务全部阻塞在锁等待上。在业务高峰期，一个事务里多调几个外部接口，整个数据库的 DML 吞吐量能肉眼可见地往下掉。更麻烦的是，锁等待时间一旦超过innodb_lock_wait_timeout（默认 50 秒），MySQL 会直接报Lock wait timeout exceeded，然后你的整个事务被迫回滚。

副作用二，隔离性带来的“状态失真”。假设你在事务里更新了订单状态为“已支付”，事务还没提交，就调用了一个外部 API，比如让下游系统来查询这笔订单的最新状态。下游看到什么？取决于它的数据源。如果它直接查你的数据库，在默认隔离级别下，它只要不跟你在同一个事务里，就看不到你未提交的修改。更常见的场景是，你的事务里更新了数据库，然后调用外部 API 做通知，外部 API 那边再回调你的另一个接口查订单状态，这时候事务还没提交，查到的就是旧数据。于是下游说“订单不存在”，你说“我刚更新过”，两边各执一词。这不是代码 bug，是事务边界没画对。

副作用三，回滚黑洞。数据库事务最大的底气是“出事可以回滚”，但外部 API 的副作用不在回滚范围内。你调了支付网关发起扣款，成功了，但后面的某个 SQL 报了死锁，事务回滚了。数据库里这笔订单是失败状态，但用户在支付平台那边的钱已经扣了。这就是所谓的“分布式事务难题”，你没有任何办法让支付平台因为你的数据库回滚而撤销扣款。除非你们之间专门设计了冲正接口，而且那个接口也得考虑对方挂掉的情况。所以，事务内调用外部 API，等于一边宣称“全有或全无”，一边又把一部分操作放在了“无法撤销”的区域里。

1.3 一个可以复盘的故障时序

我经手过一起比较典型的故障，当时是给某公司的订单系统做压测。代码逻辑很简单：用户支付成功后，系统开启事务，更新订单状态，同时调用物流下单接口，等返回运单号后再更新运单表，最后提交。听起来挺顺，但一压测就出事。

压测刚开始，某次物流接口突然抖动，响应时间从 200 毫秒变成 3 秒。由于事务还没结束，订单表和运单表上的锁一直被它攥着。几个实例同时处理相似订单时，都去锁同一范围内的主键与索引，直接引发了死锁。死锁一出现，MySQL 会自动回滚掉其中一批事务，那些事务里可能已经完成了一些外部调用，但依赖外部结果是没法回滚的。最后的结果是：数据库里部分订单更新失败，但物流那边已经出现了下单记录，运单号丢失，用户界面显示异常，还得靠事后对账一条条补。

复盘时我们把问题归结为三个点：其一，根本不应当在事务内做外部调用；其二，即使不调用物流，把多个行锁长时间握在手里，压测下也迟早出问题；其三，需要从架构上把“本地DB操作”和“外部副作用”彻底分开。那次之后，我们的代码规范里就明确多了条：事务处理的代码中禁止出现任何file_get_contents、HTTP客户端调用、RPC调用，违者必须改设计。

2. 核心决策：事务的边界到底应该画在哪

2.1 为什么Outbox模式是默认答案

既然事务内不能直接调外部 API，那正确思路是什么？我常跟团队说一句话：“你在事务里该做的只有一件事——写数据库；你对外部系统的承诺，应该写成一条待办记录，放进数据库里。”这就是 Outbox 模式，也叫本地消息表。

具体做法：在你的业务库中建一张本地事件表，比如叫event_outbox，它跟业务表在同一个事务里被写入。拿订单系统举例：

CREATE TABLE event_outbox ( id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY, biz_type VARCHAR(64) NOT NULL COMMENT '业务类型，如 order_paid', biz_id VARCHAR(64) NOT NULL COMMENT '业务单据号', payload TEXT NOT NULL COMMENT 'JSON数据', status TINYINT NOT NULL DEFAULT 0 COMMENT '0=待发送 1=已发送 2=发送失败', retry_count INT NOT NULL DEFAULT 0, next_retry_time DATETIME NOT NULL, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, updated_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, KEY idx_status_retry (status, next_retry_time) );

业务事务里只做两件事：更新订单状态为已支付，插入一条event_outbox记录，payload 里放好外部 API 需要的参数。然后一起 commit。因为这两个操作在一个数据库事务内，要么都成功，要么都失败，真正的数据一致性先保证了。

事务提交后，由另一个异步进程（定时任务、消息队列消费者都可以）去扫event_outbox，把对应数据发给外部 API。这个异步进程不在业务事务里，所以它发得慢一点、失败重试、挂掉重启，都不影响业务数据库的一致性。外部 API 收到请求，完成它的动作，可能回过头来回调你的接口，也可能不回调，你就靠消息表里的状态判断处理到哪一步了。

Outbox 模式为什么是“默认答案”？因为它把外部调用彻底移出了事务边界，而且外部系统的故障不会反向拖住你的数据库。发送失败只是留下一条待重试的记录，不会导致主业务回滚。跟分布式事务、TCC、Saga 这些方案比，它成本低得多，不需要额外引入消息中间件就能实现，而且配合幂等消费后，最终一致性是能保证的。

2.2 事务提交后的回调：PHP怎么低成本实现

有些人觉得 Outbox 要额外建表、写异步任务，太重了，想简单一点：“我就想在事务提交成功后执行一段代码，行不行？”行，方案是有的，而且不少框架原生支持。比如 Laravel 的事件系统里有afterCommit配置项，DB::transaction()提交后会触发的逻辑可以挂上去。但如果你用的还是原生 PHP 或者旧框架，没有内置钩子，那就得自己设计一套“事务后置回调”。

我分享一个比较轻的写法，适合单体 PHP 服务。核心就两步：第一步，在事务开始前创建一个小容器；第二步，业务代码里把要执行的闭包注册进容器，事务代码负责在 commit 或 rollback 后触发对应方法。

class TransactionCoordinator { private array $onCommitCallbacks = []; private array $onRollbackCallbacks = []; public function onCommit(callable $callback): void { $this->onCommitCallbacks[] = $callback; } public function onRollback(callable $callback): void { $this->onRollbackCallbacks[] = $callback; } public function commit(): void { // 这里是在事务真正提交之后调用 foreach ($this->onCommitCallbacks as $callback) { $callback(); } $this->reset(); } public function rollback(): void { foreach ($this->onRollbackCallbacks as $callback) { $callback(); } $this->reset(); } private function reset(): void { $this->onCommitCallbacks = []; $this->onRollbackCallbacks = []; } }

使用的时候，由你最外层的事务封装持有这个TransactionCoordinator，业务代码在事务里注册回调，但回调本身不在事务里执行。比如：

$coordinator = new TransactionCoordinator(); $pdo->beginTransaction(); try { // 更新订单状态 // 插入日志 $coordinator->onCommit(function () use ($payload) { $httpClient->post('https://third.example/api/notify', $payload); }); $pdo->commit(); $coordinator->commit(); } catch (Throwable $e) { $pdo->rollBack(); $coordinator->rollback(); throw $e; }

这里有个必须提醒的点：PHP 是请求结束时才结束的，如果进程在commit()之后、回调执行之前崩溃，那回调直接丢失。所以这个方案只适合“丢了能接受”的场景，或者你愿意接受“偶尔补发”。凡是通知类、支付类这种绝对不能丢的业务，别用这种内存方案，老老实实用 Outbox，把待发送记录落到磁盘上。

2.3 异步化之后必须补上的幂等能力

不管用 Outbox 也好，后置回调也好，外部 API 调用一旦变成异步，就会遇到新的问题：你发的请求，对方到底收到没？网络超时了，但对方其实处理成功了，于是你重试，结果重复下单、重复发券、重复扣款。所以，消费端必须做幂等。

幂等怎么做最有效？在你自己这边留一张“调用记录表”，以“业务幂等键”做唯一约束。比如external_request_log：

CREATE TABLE external_request_log ( id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY, idempotent_key VARCHAR(128) NOT NULL COMMENT '业务单号+接口名', api_name VARCHAR(128) NOT NULL, request_payload TEXT, response_code VARCHAR(32), status TINYINT NOT NULL DEFAULT 0 COMMENT '0=处理中 1=成功 2=失败', created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_idempotent (idempotent_key) );

异步投递者在最终发送前，用INSERT ... ON DUPLICATE KEY UPDATE的方式在external_request_log里插入一条idempotent_key。如果插入成功，说明这是第一次调用，继续发请求；如果插入时因为唯一键冲突失败，说明之前已经处理过，直接跳过，不重复请求。等到外部 API 返回成功，把这条记录的状态改成成功。如果失败，可以把状态置为失败，然后扔进重试队列。

简单讲，幂等键就是“业务单号 + 接口名”。不同接口要分开，因为同一个订单可能触发“创建物流”“发送通知”“扣减积分”三个不同请求，它们的幂等键不能一样。也不要只靠外部 API 给不给你幂等支持，自己这侧做了记录才是双重保险。

2.4 其他方案和它们的适用场景

除了 Outbox 和后置回调，还有一些场景可以补充。

延迟双删加消息队列，本质上是 Outbox 的变体，先用事务写业务表，再丢一条消息到 MQ，由消费者完成外部调用。好处是吞吐量高，缺点是你的事务和 MQ 投递之间仍然有个时间窗口，进程挂掉消息就丢了。如果消息队列支持事务消息，那就相当于把 Outbox 表的工作交给了 MQ 本身。

还有一些团队尝试用“事务前半段 + 外部调用 + 本地补偿”的方式：在事务提交前就去调用外部接口，如果后续 SQL 失败，反向调用外部冲正接口。这个方案的隐患很明显，冲正接口本身也可能挂，而且冲正结果不可控。我见过上线一年出事的，问题就出在冲正接口一小时内不可用，账目直接对不上。除了个别强一致性场景，不建议作为通用方案。

另外，如果你调的外部 API 只是只读查询，比如拉一个汇率、查一个地址解析，那我的建议是：尽量在事务之前查好，把结果作为参数传入事务。如果实在要在事务过程中查，也要明确接受“数据可能不是最新”这一代价。也就是说，事务里能查询外部，但别让外部查询的结果反过来影响事务内的写操作，否则相当于把事务的提交命运交给网络。

3. 从代码到生产：一版完整改造实录

3.1 反面写法：事务里同步请求支付网关

先来一个完整但错误的示例。假设我们有个createPayment方法，职责是创建本地支付订单，同时调支付网关生成支付单号：

function createPayment(PDO $pdo, int $orderId, float $amount): array { $pdo->beginTransaction(); try { $stmt = $pdo->prepare('INSERT INTO payment (order_id, amount, status) VALUES (?, ?, ?)'); $stmt->execute([$orderId, $amount, 'PENDING']); // 此行是万恶之源：同步调用外部支付网关 $gatewayResponse = file_get_contents('https://gateway.example.com/v1/payments', false, stream_context_create([ 'http' => [ 'method' => 'POST', 'timeout' => 10, 'content' => json_encode(['order_id' => $orderId, 'amount' => $amount]), ], ])); if ($gatewayResponse === false) { throw new RuntimeException('gateway timeout'); } $result = json_decode($gatewayResponse, true); $stmt = $pdo->prepare('UPDATE payment SET gateway_txn_id = ? WHERE order_id = ?'); $stmt->execute([$result['txn_id'], $orderId]); $pdo->commit(); return $result; } catch (Throwable $e) { $pdo->rollBack(); throw $e; } }

这段代码崩在哪？第一，INSERT后payment表相关的行锁被持有，直到外部门户返回。第二，如果网关那边返回超时，但实际业务已经成功生成支付单号，你的代码会抛异常并回滚，结果支付库里没记录，网关那边却有单子。第三，假如UPDATE payment之前发生了锁等待超时，事务回滚了，但网关那边已经收到了请求，出现了同一个订单在网关上有支付单号、本地没有支付单号的情况。

3.2 第一版改造：本地事件表加异步发布器

把上面的方法改成拿event_outbox来做：事务里只负责插入 payment 记录和 outbox 记录，然后立即提交。完整的发布逻辑放到事务外层，用一个OutboxDispatcher来做。

function createPayment(PDO $pdo, int $orderId, float $amount): array { $pdo->beginTransaction(); try { $stmt = $pdo->prepare('INSERT INTO payment (order_id, amount, status) VALUES (?, ?, ?)'); $stmt->execute([$orderId, $amount, 'PENDING']); $payload = json_encode(['order_id' => $orderId, 'amount' => $amount]); $stmt = $pdo->prepare( 'INSERT INTO event_outbox (biz_type, biz_id, payload, status, next_retry_time) VALUES (?, ?, ?, 0, NOW())' ); $stmt->execute(['payment_create', (string)$orderId, $payload]); $pdo->commit(); return ['order_id' => $orderId, 'status' => 'PENDING']; } catch (Throwable $e) { $pdo->rollBack(); throw $e; } }

支付网关的调用交给异步发布器，发布器定时拉取待发送记录：

class OutboxDispatcher { public function dispatch(PDO $pdo): void { $stmt = $pdo->query( "SELECT * FROM event_outbox WHERE status = 0 AND next_retry_time <= NOW() ORDER BY id DESC LIMIT 100" ); $events = $stmt->fetchAll(); foreach ($events as $event) { try { $gatewayResponse = file_get_contents( 'https://gateway.example.com/v1/payments', false, stream_context_create([ 'http' => [ 'method' => 'POST', 'timeout' => 5, 'content' => $event['payload'], ], ]) ); if ($gatewayResponse === false) { throw new RuntimeException('send failed'); } $result = json_decode($gatewayResponse, true); // 把网关返回的 txn_id 回写支付记录，这一步放到支付业务里处理 $this->markEventSent($pdo, $event['id'], $result); } catch (Throwable $e) { $this->markEventRetry($pdo, $event['id']); } } } private function markEventSent(PDO $pdo, int $eventId, array $result): void { $stmt = $pdo->prepare( 'UPDATE event_outbox SET status = 1, updated_at = NOW() WHERE id = ?' ); $stmt->execute([$eventId]); // 同时更新 payment 表的 gateway_txn_id } private function markEventRetry(PDO $pdo, int $eventId): void { $stmt = $pdo->prepare( 'UPDATE event_outbox SET retry_count = retry_count + 1, next_retry_time = DATE_ADD(NOW(), INTERVAL POWER(2, retry_count) MINUTE), updated_at = NOW() WHERE id = ?' ); $stmt->execute([$eventId]); } }

注意markEventSent里回写payment表时，可能会跟业务层面的并发操作冲突，比如用户已经撤销了订单。所以实际生产里我一般把这个“回写”也设计成幂等更新，只更新payment中状态仍为PENDING的记录，避免把已撤销的订单改坏。

3.3 第二版改造：手动事务钩子的PHP实现

如果你不想引入 outbox 表，又希望事务提交后立刻发起外部调用的代码可维护一点，那就用事务钩子。但前面说了，这种方案适合“丢一两条可接受”的通知场景，不适合支付核心链路。

我在这个方案里会单独封装一个TransactionScope，由它统一管理事务和钩子的生命周期，业务代码看起来会干净一些：

class TransactionScope { private PDO $pdo; private TransactionCoordinator $coordinator; public function __construct(PDO $pdo) { $this->pdo = $pdo; $this->coordinator = new TransactionCoordinator(); } public function run(callable $fn): mixed { $this->pdo->beginTransaction(); try { $result = $fn($this->pdo, $this->coordinator); $this->pdo->commit(); $this->coordinator->commit(); return $result; } catch (Throwable $e) { $this->pdo->rollBack(); $this->coordinator->rollback(); throw $e; } } }

业务侧变成：

$scope = new TransactionScope($pdo); $result = $scope->run(function (PDO $pdo, TransactionCoordinator $coordinator) use ($orderId, $amount) { $stmt = $pdo->prepare('INSERT INTO payment (order_id, amount, status) VALUES (?, ?, ?)'); $stmt->execute([$orderId, $amount, 'PENDING']); $coordinator->onCommit(function () use ($orderId, $amount) { // 在这里发起外部支付网关请求 }); return ['order_id' => $orderId, 'status' => 'PENDING']; });

onCommit里的闭包执行时，事务已经提交，数据库锁已经释放。这个方案的编码体验很直观，逻辑上从“事务内调外部 API”变成了“事务提交后的回调”，对业务侵入也不算大。但你要理解它的边界：如果回调抛出异常，异常信息只能进日志，数据库是不会再回滚的，因为事务已经提交了。所以回调里必须做充分的异常捕获，并把失败信息记录到日志或独立的重试表里。

3.4 消费者侧幂等：用一张表解决99%的重复通知

无论你选择了 outbox 还是钩子，外部 API 都有可能重复接收消息，消费端必须有幂等策略。很多团队觉得“只要我在发送端控制好不要重复发就行”，这个想法在真实网络环境下是不成立的：TCP 超时重试、消息队列 at-least-once 投递、运维手动补偿，都会导致重复。

我会在消费端建立一个event_consume_log表，也就是前面提过的external_request_log。核心逻辑用伪代码表示：

function handlePaymentNotify(PDO $pdo, string $bizId, array $payload): void { $idempotentKey = 'payment_create:' . $bizId; try { $stmt = $pdo->prepare( 'INSERT INTO external_request_log (idempotent_key, api_name, request_payload, status) VALUES (?, ?, ?, 0)' ); $stmt->execute([$idempotentKey, 'payment_create', json_encode($payload)]); } catch (PDOException $e) { if ($e->errorInfo[1] === 1062) { // 唯一键冲突，说明这个业务单号已经处理过 return; } throw $e; } // 第一次处理，调用外部API $result = callExternalApi($payload); if ($result->isSuccess()) { $stmt = $pdo->prepare( 'UPDATE external_request_log SET status = 1, response_code = ? WHERE idempotent_key = ?' ); $stmt->execute([$result->getCode(), $idempotentKey]); } else { $stmt = $pdo->prepare( 'UPDATE external_request_log SET status = 2 WHERE idempotent_key = ?' ); $stmt->execute([$idempotentKey]); } }

引发重复处理的最大场景是业务方手动重推消息，比如运营后台点了一下“重新发送通知”。有了幂等表，重复消息会被唯一键挡住，不会造成二次扣款或者重复发券。还有一个隐藏好处：幂等表本身就是一把锁，避免多个消费者并发处理同一个bizId时互相踩踏。不过注意，这里用的是数据库唯一键在并发下做互斥，如果并发量极高，可以换成 Redis SETNX 先抢锁，但最终落库判断还是以external_request_log的唯一键为准，两套都做最好。

4. 能跑一年的系统，才敢说掌握了：避坑记录与排查工具

4.1 锁等待时间、连接池与超时参数取舍

即使你把外部调用都移到了事务外，数据库锁问题并不会自动消失，你需要对事务本身的耗时保持警惕。我曾见过不少“事务里没调外部 API”但依然慢的系统，原因是某个 UPDATE 的 WHERE 条件没走到索引，几十万行被锁住，其他事务全部排队。这类问题不是本次主题的重点，但和事务健康度强相关，所以监控必须跟上。

几个和锁相关的参数值得你反复权衡：

• innodb_lock_wait_timeout：默认 50 秒。对一个在线业务来说，50 秒太久，用户早就放弃了。我一般把它调到 5 到 10 秒，让锁异常快速暴露。
• max_execution_time：这是 MySQL 给单个查询设置执行时间的上限，不是事务总时间。如果你担心长事务拖死系统，可以在 MySQ L 层设置，也可以在 PHP 侧给数据库连接设置超时。
• 连接池参数：PHP-FPM 场景一般没有连接池，每个请求独占一个连接，所以连接数量跟并发请求数相关。如果出现“连接数打满”，优先查information_schema.innodb_trx有没有长时间运行的事务，而不是盲目扩容。

说句经验话，数据库锁等待不是你最后通过调参能解决的，参数只是让问题暴露得更快。你应把“事务运行时长”“锁等待事件”作为核心监控指标，超过阈值报警，再去排查具体事务里到底做了什么。

4.2 事务和外部调用的监控怎么加

很多团队监控了接口响应时间、慢查询，但没监控“事务内运行时间分布”。我建议至少加三项：事务平均持续时间、事务持有锁的最长时间、以及每个事务处理的外部 API 次数（如果为 0 最理想）。

在 MySQL 侧，直接用performance_schema看：

-- 当前正在运行的事务 SELECT trx_id, trx_state, trx_started, TIMESTAMPDIFF(SECOND, trx_started, NOW()) AS trx_running_seconds, trx_rows_locked, trx_rows_modified FROM information_schema.innodb_trx ORDER BY trx_started ASC;

如果某事务trx_running_seconds超过 3 秒，基本可以断定它里面藏着不该有的外部调用或慢 SQL。再查一下events_statements_summary_by_digest，定位具体是哪些 SQL 消费了时间。

如果是 PHP 侧，建议在TransactionScope::run()开头和结尾打点，记录事务耗时；同时在onCommit回调里记录外部 API 的耗时。这样在日志链路里能清晰看到“数据库事务用了多少毫秒，外部 API 回调用了多少毫秒”，定位问题快很多。

监控还有一个关键作用：帮助团队守住规范。以前代码 review 时总有人把file_get_contents写进事务块里，后来我们在TransactionScope::run()里放了一个“保险丝”，在事务执行期间如果检测到向外发起 HTTP 请求（通过自定义 HTTP 客户端封装做统计），直接抛异常。这个做法比较霸道，但对于核心交易链路，我宁可拦错，不可放过。

4.3 踩坑速查表

这里整理了一份我在实际运维中遇到过的典型问题，几乎每一行都对应着真实的工单。

排查工具里最常用的一定是show engine innodb status，它的输出里有最近死锁的详细记录，包括持有锁的会话、等待锁的会话、涉及的表和行。另一个是performance_schema.events_statements_history_long，可以倒查某个长事务在提交前执行了哪些语句，确认是不是在事务里偷偷调用了外部服务。

另外，MySQL 8.0 里可以开innodb_print_all_deadlocks=ON，把所有死锁信息直接打印到错误日志，比现场抓show engine innodb status可靠得多。这套配置建议加上，生产环境至少能给你留出事后溯源的证据。

最后补充一个排查外部 API 故障的经验：不要只盯着你的应用日志，还要关注网络层，特别是 DNS 解析超时、TCP 连接复用、代理层 499/502 这类边界情况。这些故障表现出的现象往往都是“事务过程中 HTTP 卡住”，如果你把外部调用挪出事务，数据库就不会被殃及，故障半径会小很多。

我个人在这些改造里踩过不少坑，印象最深的还是那句话：事务只管数据库自己的事，对外部的每一次承诺，都应该在下一次可靠投递里兑现，而不是靠一次同步请求赌命。至少在我维护过的系统里，坚持这个原则的项目，夜班电话明显少多了。