假设A调用B，B调用C，只有C方法涉及到多张表的增删改操作，那么@Transactional注解添加在A方法上，和添加在C方法上，哪个性能更好？
要判断 @Transactional(rollbackFor = Exception.class) 加在 A方法 还是 C方法 上性能更好，核心结论是：加在C方法上性能更优，且更符合事务设计的“最小粒度原则”。下面从原理、性能差异、场景适配三方面详细分析：
一、先明确核心前提（避免理解偏差）
你提到“只有C涉及多张表的增删改”，A和B仅为调用链路（无数据库操作），因此事务的核心作用是保证C中多表操作的原子性（要么全成，要么全回滚）。基于这个前提，事务粒度越小，性能损耗越低。
二、性能差异的核心原因：事务的“生命周期”
Spring事务的本质是数据库连接的事务管理（通过AOP拦截方法，在执行前开启事务、执行后提交/回滚，期间占用数据库连接）。性能损耗主要来自：
- 事务占用连接的时长（连接是稀缺资源，长时间占用会导致连接池耗尽风险）；
- 事务期间数据库的锁竞争（事务未提交时，会持有表锁/行锁，粒度越大锁持有时间越长）；
- 事务日志的刷盘开销（事务越大，日志量越多，提交时刷盘成本越高）。
对比两种方案的事务生命周期：
| 事务注解位置 | 事务生效范围 | 连接占用时长 | 锁持有时长 |
|---|---|---|---|
| A方法 | A→B→C的全链路（包括A、B的非数据库操作） | 最长（从A开始到A结束，包含B的调用耗时、A的其他逻辑耗时） | 最长（C执行完后，需等待A剩余逻辑执行完才释放锁） |
| C方法 | 仅C方法内部（仅包含多表增删改操作） | 最短（仅C执行的时间，不包含A、B的调用开销） | 最短（C执行完立即提交/回滚，快速释放锁） |
三、具体性能损耗点对比
1. 连接资源占用：C方法更高效
- 若加在A方法：假设A方法包含“参数校验→调用B→调用C→后续业务逻辑（如日志记录、调用第三方接口）”，整个过程中数据库连接会被事务占用，直到A方法完全执行完毕才释放。如果后续业务逻辑耗时较长（如第三方接口响应慢），会导致连接池中的连接被长时间占用，其他请求可能因获取不到连接而阻塞，系统吞吐量下降。
- 若加在C方法：仅在C执行多表操作时占用连接，C执行完立即释放，连接利用率极高，几乎不会影响其他请求。
2. 锁竞争：C方法冲突更少
- 若加在A方法：C执行完多表操作后，事务未提交（需等A后续逻辑），此时C操作的表/行会被锁持有。如果其他请求也需要操作这些表/行，会发生锁等待，甚至死锁（极端情况），导致响应延迟。
- 若加在C方法：C执行完立即提交，锁快速释放，锁竞争时间窗口极小，冲突概率大幅降低。
3. 事务日志与提交开销：C方法更轻量
数据库事务提交时，需要将事务日志（redo log/undo log）刷盘保证持久性。事务粒度越大，日志量越多，刷盘耗时越长；反之，C方法的事务仅包含必要的多表操作，日志量小，提交开销可忽略。
四、补充：是否影响事务原子性？
有人可能担心“加在C方法上，A调用B再调用C，是否会破坏原子性？”——答案是不会，因为：
- 只有C有数据库操作，事务的原子性只需要保证C内部的多表操作一致即可，A、B无数据库操作，不存在“回滚A/B逻辑”的需求；
- 若C执行失败，事务回滚C的操作；若C执行成功，事务提交，完全满足业务需求。
反而加在A方法上会“过度事务”：A的非数据库操作（如日志、第三方调用）失败时，会导致C已成功的数据库操作回滚，这可能不符合业务预期（例如：C的订单创建成功后，A的日志记录失败，不应回滚订单）。
五、特殊场景例外（极少情况）
如果A方法除了调用B→C，还包含其他数据库操作（例如：A先插入一条记录，再调用C修改其他表），且需要保证“A的操作 + C的操作”原子性（要么全成，要么全回滚），则必须加在A方法上——此时性能是次要的，原子性是核心需求。但根据你的描述，A、B无数据库操作，因此这种场景不适用。
最终结论
- 性能优先级：C方法 > A方法（事务粒度最小，连接占用、锁竞争、提交开销均最优）；
- 设计合理性：C方法更符合“事务仅包裹必要操作”的原则，避免过度事务导致的性能问题和业务风险；
- 建议：将
@Transactional(rollbackFor = Exception.class)仅添加在C方法上。