不能在MySQL事务中调用外部API，因其违背ACID语义：导致连接池耗尽、锁持有过长、本地回滚无法撤销远程副作用，必须分离为“先API后短事务”，通过幂等、补偿和前置校验实现最终一致性。
不能在 MySQL 事务中“优雅地处理”外部 API 调用的异常——因为根本不该让它进事务。
为什么 START TRANSACTION 里调 curl 或 http.Client.Do 是设计错误
这不是写法不够“优雅”，而是语义冲突：数据库事务保证的是本地、快速、可回滚的原子操作；HTTP 请求是远程、延迟不可控、副作用不可撤销的网络行为。两者混在一起，会直接触发以下连锁反应：
- 事务持有时间被拉长，
SELECT FOR UPDATE锁住的行长期阻塞其他写请求 - HikariCP 等连接池迅速耗尽（默认 10 连接 + 30 秒超时），连只读查询都开始排队失败
- API 成功返回了，但 DB 连接因超时被强制关闭 → 事务回滚，数据静默丢失
- 哪怕你捕获了
Deadlock found when trying to get lock或SQLException，也救不回已经发出去的 API 请求
应用层必须显式分离：先 API，后事务
把外部调用移出事务边界，不是妥协，而是唯一可控的路径。关键动作是：验证响应有效性 → 构建确定性输入 → 开启短事务执行 DML。
- 对 API 响应做严格校验：
status == 200且body.data.id非空，才进入下一步；否则直接降级或告警 - 所有重试、超时、幂等 key（如
X-Idempotency-Key）必须在事务外完成，避免重复提交 - 事务内只做三件事：查（
SELECT ... FOR UPDATE）、改（UPDATE）、插（INSERT），全程控制在 100ms 内 - 若 API 返回“结果未知”（如超时、连接中断），必须走补偿流程（如定时任务轮询 + 对账），不能靠事务回滚掩盖
MySQL 存储过程中误用 DECLARE HANDLER 的典型陷阱
有人试图在存储过程里封装 API 调用（比如用 Sys_exec 或 UDF），再配 DECLARE EXIT HANDLER FOR SQLEXCEPTION —— 这完全无效。
- MySQL 不允许在事务中执行系统命令或外部网络调用；强行调用会直接报错退出，handler 根本不触发
- 即使绕过限制（如用
curl+sys_exec），handler 只能捕获 SQL 层错误（如 1062 主键冲突），无法感知 HTTP 超时或服务不可达 -
GET DIAGNOSTICS拿不到 HTTP 响应体，ROW_COUNT()对外部调用毫无意义 - 真正该用 handler 的地方，是处理
INSERT失败后的分支逻辑（如主键冲突时转UPDATE），而非给 API 打补丁
Java/Python 中真实可行的异常响应链
事务异常处理的成败，90% 取决于应用层是否主动控制回滚时机，而不是依赖框架自动行为。
- Spring 用户别迷信
@Transactional+@Retryable：第一次死锁回滚后，第二次重试是在新事务里跑，但业务状态（如库存）可能已被其他请求修改，盲目重试导致超卖 - 正确做法是用
TransactionTemplate手动开事务，每次重试前检查前置条件（如SELECT stock FROM items WHERE id = ?） - Python（SQLAlchemy）必须在每次死锁捕获后调用
session.rollback()和session.close()，否则 session 进入 invalid 状态，后续commit()必报错 - 所有
SQLException都要检查e.getSQLState()：死锁是40001，主键冲突是23000，不能只靠getMessage()字符串匹配
最常被忽略的一点：API 调用和数据库操作之间没有“中间态”。要么你接受最终一致性（用消息队列+补偿），要么就接受它俩根本不能放在一个事务里——后者不是缺陷，是分布式系统的物理事实。
