为了避免其他人再误解，我举个例子：计算访问量，访问一次在原基础上加1。此回答是基于该想法进行的回答。没有关联，没有业务，单纯的操作数据

同意，方法是单一的，但是请求可能是有并发的，修改操作建议都加事务

还别听上面乱讲，sql单行操作时，命中索引对索引加锁，没有命中对行加锁，了解下？操作失败不操作不相当于回滚？

@让我发会呆: 单行操作自动添加排他锁，跟并不并发无关，解决并发那是其他解决方案

@TenFly: 你这上面说的两个回复，简直不敢苟同。
什么系统是只有一个人使用，不会出现并发？你的业务接口设计只能串行访问？

楼主说的是基础的增删改查之类的操作，你要是 delete from table_name; 这种操作确实是不需要在事务里，只要是你的更新sql有一点业务逻辑在里面，你不加事务试试，除非你的系统tps非常低，才不太会经常出问题吧。

@让我发会呆: 我觉得了解一下数据库的底层原理比敲一年的CRUD强，数据库在执行更改操作时会加上排他锁，这是一种单例操作，基于楼主的提问“不跟其他业务关联的更新操作”需要什么事务，全都是排着队的请求。事务是更新关联的数据，比如两条数据关联必须同时成功、或者一条数据的更新有执行顺序关系才会使用。

@让我发会呆: 我声明一边我回复的立场，不跟业务关联，单纯的更新没关联的数据

@TenFly: 秒杀场景，一万个人抢两个库存商品，这是单表吧，也是排着队的请求吧，和更新的执行顺序也没关系吧，你来段代码，不要事务控制，也不许加锁，保证不多卖，show me the code

@让我发会呆: 你这不是跟业务挂钩了吗？我一个库存表，每次请求接口数量减1，发一万次，减少一万条，并发一亿次，减少一亿条，单纯的数据更新不需要事务。等你将实际数据跟业务挂钩，像你说的库存不能小于0，这才有使用事务的意义

@让我发会呆: 我懂你回答的意思，只能说审题结果不一致，你看楼主需要的是那种回答

@让我发会呆: 事务不是sql执行中,有一条失败,事务中的所有语句都回滚么? 秒杀场景下, 加上事务, sql语句更新成功了, 东西卖超了,它也能回滚么?

@百鸟朝凤: 当然不能回滚，加事务是可以让你在事务代码里实现你的业务逻辑，保证不会卖超，如果没有事务是很难做到的

@让我发会呆: 那这种, 直接加锁, 然后更新语句加一个where 条件, 库存不能小于0 ,不可以么,不用事务

@百鸟朝凤: 不想讨论这个问题了，博主说的简单sql单表操作，这种事务可加可不加，主要看具体业务，我说的场景也是，库存不能小于0一个where 条件就可以了，那如果单表有很多字段都需要调整，不可能把全部业务逻辑写在sql里吧。

我最初说的修改操作建议都加事务，只是平时的业务开发规范，对于以后的代码维护和代码复用都是有好处的。

@让我发会呆: 嗯嗯, 主要是我原来从来没考虑过这些,一直以为事务就是多条sql执行,其中一条报错, 全部回滚, 没考虑到在事务中加业务代码, 所以多问了两句

@百鸟朝凤: 事务其实就是多条sql执行,其中一条报错, 全部回滚， 我是搞java的，一般使用都是spring的事务管理器，这个事务回滚功能其实也就是使用数据库的rollback。

事务里一般做的加锁读，还需要考虑到数据库的不同隔离级别，就是那些不可重复度、幻读、写倾斜那些怎么处理，spring的事务还有7种传播机制，事务与事务之间的处理。

你要是有幸遇到业务上面的事务不一致问题，带着问题去分析，就更好玩了 = =

@让我发会呆: 我的理解是, 我要执行sql语句,前提是我的业务逻辑判断一般都完成之后才会执行,怎么会出现在事务中写业务逻辑呢,就像那个秒杀,我应该是先判断目前的库存,如果大于0, 我才执行sql语句啊, 我不会先执行sql, 然后再判断库存,发现库存不对再回滚,,,,
可能是我遇到的业务场景太少了,大部分都是增删查改, 还没啥大并发的场景,单纯考想,还真想不出这种场景

@百鸟朝凤: 兄弟，你要是在开始事务之前先做业务逻辑判断，那是没用的，因为等你进去事务去执行sql的时候，数据库里面的数据可能已经修改了，已经不满足你之前做的逻辑判断了，你必须要事务里 在加锁读之后做业务逻辑判断，才可能不会出问题。

你好，在"并发控制"中你的意思是"事务可以确保同一时刻只有一个用户对数据进行修改"吗？但是我觉得数据在被修改的时候是加了“写锁”的，即便我不开启事务，同一时刻也只能有一个用户对数据进行修改。"同一时刻只有一个用户对数据进行修改"这个好处是和锁有关系，和事务没关系吧？