事务中远程调用会导致连接长时间占用且一致性失控：MySQL连接在事务中无法归还连接池，远程超时与事务超时错位易致连接耗尽，本地ACID无法保障远程操作，应拆分事务边界，用异步+幂等+补偿实现最终一致性。
事务中远程调用会导致连接长时间被占用
MySQL 连接在事务开启后，直到 COMMIT 或 ROLLBACK 才会释放锁、清理事务上下文，但连接本身仍由客户端持有着。如果事务里夹着 HTTP 请求、RPC 调用或消息队列发送等远程操作，这个连接就卡在“已开启事务但没结束”的状态，无法归还给连接池。
常见现象是：数据库监控显示 Threads_running 不高，但 Threads_connected 持续攀升，大量连接处于 Sleep 状态且 Command 为 Sleep、State 显示 in transaction —— 实际上它们正等着远端服务响应。
- 连接池（如 HikariCP）默认配置下，空闲连接超时（
idleTimeout）通常不回收“正在事务中”的连接 - 应用层若未设远程调用超时，可能让连接挂住几十秒甚至几分钟
- 高并发下极易触发连接池耗尽，新请求在
getConnection()阶段阻塞或直接抛Unable to acquire JDBC Connection
远程失败时事务回滚逻辑难以保障
本地事务和远程服务属于不同一致性边界，MySQL 的 ACID 对远程操作完全无感知。你写了个 try...catch 包住远程调用再手动 rollback()，看似稳妥，实则存在多个断裂点：
- 远程服务返回成功，但网络抖动导致响应丢包，客户端误判为失败而回滚 —— 实际上游已执行，造成“重复提交”或“状态不一致”
- 远程调用成功，但后续本地
COMMIT因数据库宕机失败，此时无法反向通知远端补偿，产生悬挂事务 - 若用的是自动提交关闭 + 手动控制的事务模板（如 Spring
@Transactional），远程调用抛异常后事务虽标记 rollbackOnly，但若方法内还有其他 DB 操作，可能触发TransactionSystemException，掩盖真实原因
典型错误日志：org.springframework.transaction.UnexpectedRollbackException: Transaction rolled back because it has been marked as rollback-only，往往就是混入了不可控的外部副作用。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
超时配置错位放大雪崩风险
事务超时（如 Spring 的 timeout 属性）、JDBC socket timeout、HTTP client timeout、远程服务自身 timeout 四者之间没有天然对齐。最容易出问题的是：事务超时时间 > 远程调用最大可能耗时。
- 例如设置了
@Transactional(timeout = 60)，但 HTTP 客户端只配了connectTimeout=3s, readTimeout=10s，结果远程服务卡在中间件排队，12 秒才返回 —— 本地线程已继续往下走，事务却还在开着 - MySQL 层面的
wait_timeout（默认 8 小时）和interactive_timeout一般远大于业务需求，不会主动断连，反而让“僵尸事务连接”更难被发现 - 某些云数据库（如阿里云 RDS）会主动 kill 掉空闲过久的连接，但 kill 时机与事务状态无关，可能导致
MySQLNonTransientConnectionException: No operations allowed after connection closed
替代方案要拆开事务边界与远程动作
核心原则是：让 MySQL 事务只管本地数据一致性，远程动作移出事务范围，靠异步+幂等+补偿来兜底。
- 写操作分两阶段：先落库（带状态字段，如
status='pending'），COMMIT后再发 MQ 或调远程；消费端查库+校验幂等键后执行 - 必须同步等待远程结果的场景，改用最终一致性模型：记录操作日志表（含重试次数、下次执行时间），用定时任务扫描驱动
- 若坚持要在同一方法内处理，至少确保远程调用有硬超时（如 OkHttp 的
call.timeout(3, TimeUnit.SECONDS)），并捕获所有异常分支做明确 rollback，同时记录完整上下文便于排查
真正麻烦的从来不是“能不能写”，而是“出错时系统能否自解释发生了什么”。事务里塞远程调用，等于把数据库的确定性，绑上了网络的不确定性。
