引发思考
今天，发现开发项目中的单号重复了。
这是多用户并发操作相同数据导致的结果。有点抽象，理解如下：实际就是多个事务交叉执行（增、删、查、改）了相同数据。导致一个事务不具有完整性了，数据库的数据也不一致了（这里‘’一致‘’可以理解为：我希望的数据，跟我想像的不一样，比如明明我刚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事务结束之前，该行数据都不能被其他事务修改（增、删、改），但是其他事务可以读改行数据。其他事务永远都不能拿到该行数据的排他锁，排他锁的作用是独自占据数据的增、删、改操作。
这篇文章不过抛转引玉罢了，官方的就很齐全了 https://docs.microsoft.com/zh-cn/sql/relational-databases/sql-server-transaction-locking-and-row-versioning-guide?view=sql-server-2017