咱们得从**数据库的“本能”和业务的“扩展”**两个维度来看。1. 数据库的“本能”隐式事务其实即使你不写Transactional数据库也不是完全没有防备的。单条 SQL 是自带“防弹衣”的所有的主流数据库如 MySQL默认都开启了autocommit自动提交。断电会怎样当你执行一条UPDATE或INSERT语句时数据库内部会把它当成一个“微型事务”。如果 SQL 刚发过去还没执行完就断电了数据库重启后会回滚数据不变。如果 SQL执行完并自动提交了断电就没影响数据已经落盘。结论对于真正的单条 SQL加不加Transactional在原子性上的效果是一样的。2. 为什么“单功能”通常不加在若依或者很多项目中单查询、单删除、单修改不加注解主要有三个原因性能开销开启事务是需要“打招呼”的向数据库申请资源、锁定行、记录日志。如果只是一个简单的查询或单表更新加了事务反而会让程序变慢一点点。只读查询不需要如果是select语句根本不涉及改数据加事务完全是浪费资源。代码整洁程序员追求“按需分配”。既然一条 SQL 就能解决战斗就没必要请“事务大管家”出面。3. 关键点什么是“单功能”老弟这里有个坑你得看准了。很多看起来是“一个动作”的功能背后其实是多条 SQL。哪怕现在是单条以后变了怎么办场景一现在只是deleteUser(id)是一条 SQL。场景二明天老板说删除用户的同时要把他的头像文件也删了还要给管理员发个通知日志。这时候deleteUser里面就变成了三四个动作。结论如果你预感到这个方法以后会变复杂或者它虽然现在只有一行代码但调用了其他的 Service 逻辑保险起见加上它是更好的习惯。️ 什么时候“必须”加金科玉律只要满足以下任一条件必须加不管它看起来多简单多表操作同时修改 A 表和 B 表。循环操作在一个for循环里不停地调 Mapper 改数据只要其中一个失败前面的都要撤回。先查后改先查询余额判断一下再去扣钱。这涉及到数据的一致性必须加事务锁住数据。调用了多个 Mapper 方法哪怕是同一个 Mapper 的两个不同方法。建议虽然单条 SQL 靠数据库本能能抗住但作为新手哥建议你遵循这个原则凡是涉及“增、删、改写操作”的业务方法统一加上Transactional。理由现在的电脑和服务器性能都很强这点开销微乎其微。防止你以后在方法里加了新逻辑却忘了补注解导致数据错乱这种 Bug 极难排查。显得你很有安全意识代码风格统一。答案是个人想法加上准没错查询除外