多个用户同时对数据库的并发操作时，可能会遇到下面几种情况，导致数据不一致：
1，A、B同时对同一个数据进行修改，后提交的人的修改结果会破坏先提交的（丢失更新）；
2，A修改某一条数据并提交，B读取这个数据，之后A取消了对数据的更改，此时B的数据就会和数据库不一致（脏读）；
3，A读取某一数据，之后B修改了这个数据，A再读这个数据时发现前后两次的数据不一致；
针对这些并发的问题，解决的办法就是对操作的数据进行加锁。
锁的种类有以下几种：
1，共享锁（S）：用于不修改的数据（SELECT语句），在一个事务读取某数据时，获取它的共享锁，任何其它事务都无法修改该数据，直到该事务释放共享锁。共享锁不会影响其它事务获取该数据的共享锁。
2，排它锁（X）：一个事务获取到某数据的排它锁，则其它事务无法读取或更改该数据，直到该事务释放排它锁。
3，更新锁（U）：一次只有一个事务可以获取资源的更新锁，如果该事务修改资源，则更新锁转换为排它锁。（避免死锁的出现）
4、意向锁：用于建立锁的层次结构。意向锁的类型为：意向共享 (IS)、意向排它 (IX) 以及与意向排它共享 (SIX)。
5、架构锁：在执行依赖于表架构的操作时使用。架构锁的类型为：架构修改 (Sch-M) 和架构稳定性 (Sch-S)。
6、大容量更新 (BU) ：向表中大容量复制数据并指定了 TABLOCK 提示时使用。
死锁：A、B两个事务都获取了某个数据的共享锁，A需要更新数据，需要等待B释放共享锁，同时B也要修改数据，要等A释放共享锁，然后A、B就互相等待造成死锁。
悲观锁和乐观锁
悲观锁：顾名思义，就是很悲观，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会block直到它拿到锁。
乐观锁：顾名思义，就是很乐观，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号等机制。
两种锁各有优缺点，乐观锁适用于写比较少的情况下，即冲突真的很少发生的时候，这样可以省去加锁的开销，加大了系统的整个吞吐量。但如果经常产生冲突，上层应用会不断的进行retry，这样反倒是降低了性能，所以这种情况下用悲观锁就比较合适。
锁的粒度（范围）：是指被封锁目标的大小
锁的粒度和锁的类型都是由SQL Server进行控制的（当然你也可以使用锁提示，但不推荐）。锁会给数据库带来阻塞，因此越大粒度的锁造成更多的阻塞，但由于大粒度的锁需要更少的锁，因此会提升性能。而小粒度的锁由于锁定更少资源，会减少阻塞，因此提高了并发，但同时大量的锁也会造成性能的下降。