项目中如何选择是否使用事务？

Question

之前在学习过程中，对多表的操作一般添加事务，防止多表操作过程中， 一部分表更改成功， 另一部分表没有更改成功，会出现脏数据。但是最近实习的时候，项目中基本没有事务机制。问了一下师兄，师兄说了以下原因：

1. 一般脏数据都出现在测试阶段。如果项目代码逻辑正确（经过严密测试通过），一般不会出现脏数据。
2. 很多时候，问题出现在网络延时，这时候即使使用了事务，只会一遍遍重复。
3. 加事务会大大增加代码的耗时，而一般脏数据很少出现，出现脏数据时进行数据订正的代价更小。

有没有大佬给指导一下什么时候采用事物，什么时候不需要？

问题描述

问题出现的环境背景及自己尝试过哪些方法

相关代码

粘贴代码文本（请勿用截图）

你期待的结果是什么？实际看到的错误信息又是什么？

Answer 1

你师兄说的有点儿道理，但显然没说全。

你师兄说的“数据订正”，显然也不能是人工去订正，那得累死，而是系统自动的补偿机制。

用不用事务就一个原则：当你的操作非原子性、并且一旦出现问题会影响业务流程时，就需要用事务。

原子性就不提了，这你还不知道就建议重读本科了。说下什么叫“会影响业务流程”。

比如微博点赞这个场景（假设他们用的是数据库来存储的），一般会有一个点赞记录表，而被点赞那条评论数据还会有一个汇总点赞数量（为啥会有这个而不是每次临时 COUNT 是另一个问题）。

正常流程来说是，你点赞了，点赞记录表插入一条记录、相应的评论点赞数 +1。你要说这中间出问题了，记录表已经插入了、但点赞数没 +1 怎么办？

不怎么办。这个数真的错了就错了，完全对业务系统不造成什么影响。这个数据完全可以等待一段时间后后台再去补偿修正更新，并不需要时时刻刻显示的都是最真实的那个数值。相反，如果你用了数据库事务，存在锁，会导致并发性能急遽下降，那么面对微博点赞这种瞬时海量操作，什么数据库也扛不住。

另外还有一点，你要分清到底是需要“事务”还是“数据库事务”。上一些规模的业务系统往往是分布式架构，还需要引入分布式事务，而分布式事务往往不依赖数据库事务实现。这是另一个话题了，就不展开了。

最后的最后，抛开场景谈架构都是耍流氓。如果你的业务系统访问量很小，并发量微乎其微，你大可以所有非原子性操作都用数据库事务，只要数据库能扛得住，完全没什么问题呀。这种情况下你要非得上什么补偿机制什么分布式事务，那真是杀鸡用牛刀。

Answer 2

一般脏数据都出现在测试阶段。如果项目代码逻辑正确（经过严密测试通过），一般不会出现脏数据。

事务是防止并发下产生脏数据，和业务逻辑错误产生的脏数据无关

很多时候，问题出现在网络延时，这时候即使使用了事务，只会一遍遍重复。

看不懂啥意思，事务不是重试，重试的不一定是事务，两者没有直接联系

加事务会大大增加代码的耗时，而一般脏数据很少出现，出现脏数据时进行数据订正的代价更小。

头一次听说事务性能损耗这么大的，但是如果出现了大量的脏数据，修起来就不是一天两天的事情了，目测系统用户不多数据不多业务不复杂。。。

Answer 3

1、你这个师兄说的是错的
2、事务绝对是必须的
3、你看不见事务，不代表没有事务，你只要执行了 sql 实际上就打开了事务，看不见是因为被框架隐藏了
4、事务是会有耗时，但是合理的使用事务反而能降低耗时
5、在需要写数据的时候加事务
6、你能保证代码逻辑不出错，但是你能保证与代码交互的外界环境不出错吗？

在你的框架里面看起来没有开启事务，但是实际上你翻过源码就会发现，orm 框架在最终执行 sql 时会判断当前线程是否已经打开了事务，如果没有，就会自己打开一个，然而不断的打开事务代价是比较大的。

比如批量 for 循环插入数据，每一次插入都打开事务；和一次打开事务，最终提交。打开一次事务的做法不论是出现异常的处理还是性能要都要优于每一次插入都打开事务。

而且在高并发与需要细腻处理数据的场景下，一定要善于使用事务，否则会经常出现数据不一致的情况。

Answer 4

反正我怕锤，我得加事务