事务锁

引发思考

今天，发现开发项目中的单号重复了。

这是多用户并发操作相同数据导致的结果。有点抽象，理解如下：实际就是多个事务交叉执行（增、删、查、改）了相同数据。导致一个事务不具有完整性了，数据库的数据也不一致了（这里‘’一致‘’可以理解为：我希望的数据，跟我想像的不一样，比如明明我刚update某表性别为男，我update完它还是女的，如果别人要修改，也得等我update完再改呀！咦，统计男生的总人数的确是加1了，见鬼了）。

并发操作数据的不利影响

多个用户试图修改其他用户正在使用的资源时总是会产生负面影响。（这里用户可以理解成事务，用户这个词组总是在不同场合出现，例如redis客户端用户，b/s模式客户端用户，这些情况其实可以广泛理解为请求）

更新丢失：a事务里更新某些数据，a还没结束运行。这段时间，b插足一脚，也更新了那些数据，覆盖了a刚更新完的，a白更了。一段时间后，a正常结束了，a丢失了更新的数据。

脏读：b正在修改某些数据，还没结束运行。这段时间a去读那些数据，但读的不是b修改之后的，而是b修改之前的。一段时间后，b正常结束了，a读的数据还是旧数据。

不可重复读：9点钟，a在读某部分数据。9点半，b修改了那部分数据，b结束运行了。10点钟，a又回头读那部分数据，发现数据和9点钟的不一样。a读的是同一部分，却返回不一样的数据。

 幻读：9点钟a根据条件取了一个结果集看看，还没结束运行。9点半，b删除了那个结果集部分行数据，又新增了部分行数据。10点，a根据相同条件取结果集，发现新增了部分，删除了部分，刚刚是在做梦吧？

总而言之，一旦小三插足干坏事，我就完了。

事务锁

针对上面的问题，可以使用事务锁解决。（事务锁是一种悲观的解决方案，）

每个事务里可能涉及行数据、页数据、表数据、，这数据相等事务依赖的资源，当请求操作这些资源，可以请求不同类型的锁。 该锁可以阻止其他事务以错误方式操作该资源。 当事务不再依赖锁定的资源时，它将释放锁。

简单说，这些数据可以被上锁、上锁后，其他事务对该数据的操做就有限制了，不是你想改就能改，你想读就读。我锁是大爷，我允许，你就能操作；我若不许，你就滚出去！

 

锁粒度： sql server具有多种粒度锁定，例如行粒度、表粒度、数据库粒度......

如果在较小的粒度（例如行）加锁，可以提高并发度，因为对其他事务限制范围小，只是开销较高，锁定了多少行，则需要多少锁。

比如a事务拿到了某行数据的某锁，该限制了其他事务对该行数据的操作，但是其他事务不一定要操作该行，也是就1两个事务需要操作改行，

如果在较大的粒度（例如表）加锁，则会降低并发度，因为锁定整个表限制了其他事务对表中任意部分的访问。 但开销较低，因为需要维护的锁较少。

 

锁类型：共享锁、排他锁等。锁与锁之间是可以冲突的。比如a事务拿到了某行数据的共享锁，说明a事务结束之前，该行数据都不能被其他事务修改（增、删、改），但是其他事务可以读改行数据。其他事务永远都不能拿到该行数据的排他锁，排他锁的作用是独自占据数据的增、删、改操作。

 

这篇文章不过抛转引玉罢了，官方的就很齐全了