Spring Boot @Transactional方法性能开销过大排查求助

问题描述 #

我们使用Spring Boot（3.5）服务连接Azure托管的MySQL 8数据库时，发现调用标注@org.springframework.transaction.annotation.Transactional的方法存在大量性能损耗。经排查，动态代理内部的耗时是服务方法内部耗时的2-4倍（例如P50：Measure A为16ms，Measure B为6ms；P99：Measure A为42ms，Measure B为16ms），已通过以下简化代码复现该问题：

@Controller
@RequiredArgsConstructor
public class TransactionPerformanceInvestigatingController {

    private final TransactionalTestingService transactionalTestingService;

    @GetMapping("/transaction-performance-investigating")
    @ResponseBody
    public Object investigate() {
        // Measure A start
        transactionalTestingService.doSomething();
        // Measure A stop
        return "done";
    }
}

/////////////////////////////////////////////////////////////////////

@Component
@RequiredArgsConstructor
class TransactionalTestingService {

    private final ShopTenantProvider provider;

    @Transactional(readOnly = true)
    public Object doSomething() {
        // Measure B start
        final List<ShopTenant> result = provider.getAll();
        // Measure B stop
        return result; 
    }
}

已排除以下因素：连接池大小无问题、获取连接及设置autocommit为false耗时短（3ms）、提交操作耗时可忽略（查询无提交内容）、本地MySQL无此现象。现寻求解答：

1. 该场景下具体存在哪些机制导致耗时？
2. 如何深入排查耗时原因（当前NewRelic无法追踪代理内部操作）？
3. 此开销是否属于正常情况？

相关技术栈：MySQL Server为Azure托管服务、持久化采用JPA与spring-boot-data-jpa、驱动为com.mysql.cj.jdbc.Driver、连接池为hikari并包装于datasource-proxy。

解答 #

1. 可能导致耗时的核心机制 #

• Azure跨网络的延迟放大效应：Azure托管数据库与应用服务存在跨网络调用，Spring事务代理的额外操作（事务上下文创建、传播属性检查、连接绑定/解绑）会叠加网络延迟。本地环境无此问题，说明网络是核心诱因。
• Datasource-proxy的拦截开销：datasource-proxy会对连接、语句执行全链路拦截，事务过程中代理层的日志、监控或校验逻辑，在跨网络场景下被放大，成为耗时的叠加项。
• Spring事务上下文的线程绑定逻辑：@Transactional触发的动态代理需要将数据库连接绑定到当前线程，同时初始化事务上下文、检查传播行为，这些操作本身有基础开销，在网络环境下，与数据库相关的连接属性校验等步骤耗时被放大。
• JPA事务同步的额外操作：Spring Data JPA在事务开启时会同步EntityManager，执行一级缓存初始化、事务状态跟踪等操作，远程数据库场景下这些步骤的网络交互成本被放大。

2. 深入排查的具体方法 #

• 用Arthas做方法级追踪：执行trace org.springframework.transaction.interceptor.TransactionInterceptor invoke命令，直接追踪事务拦截器的执行链路，查看每个内部步骤的耗时，定位是事务创建、连接绑定还是其他环节拖慢速度。
• 开启Spring事务DEBUG日志：在配置文件中添加logging.level.org.springframework.transaction=DEBUG，通过日志时间戳分析事务创建、传播、资源绑定等每一步的耗时细节。
• 移除datasource-proxy做对比：临时去掉datasource-proxy的包装，直接使用Hikari连接池，验证代理层是否是主要耗时来源。
• 生成线程栈快照：在请求高峰期用jstack导出线程栈，查看事务代理执行时线程的状态，确认是否存在网络IO等待或锁竞争。
• 查看Azure MySQL监控指标：在Azure控制台查看数据库的连接延迟、事务处理时间等指标，确认是否是数据库端的只读事务一致性检查等操作导致额外耗时。

3. 该开销是否正常 #

这种代理耗时达到业务方法2-4倍的情况不属于正常范围。正常情况下，Spring事务代理的额外开销应控制在1ms以内，即使加上网络因素，也不应达到业务方法的数倍。结合本地环境无此现象，说明问题是Azure网络环境与代理层逻辑叠加导致的异常耗时，需要针对性排查修复。

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