多个用户同时对数据库的并发操作时，可能会遇到下面几种情况，导致数据前后不一致：
1，A、B事务同时对同一个数据进行修改，后提交的人的修改结果会破坏先提交的（丢失更新）；
2，事务A修改某一条数据还未提交，事务B读取了这个未提交的数据，之后A回滚了对该数据的修改，此时B读到的数据就会和数据库不一致（脏读）；
3，事务A读取某一数据，之后B修改了这个数据，A再读这个数据时发现前后两次的数据不一致（不可重复读）；
4，事务A检索到条件范围内的数据为N行，同时事务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直到它拿到锁。悲观锁是由数据库自己实现了的，要用的时候，我们直接调用数据库的相关语句就可以了。
乐观锁：顾名思义，就是很乐观，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号等机制。通常乐观锁实现是这样的：在表中的数据进行操作时(更新)，先给数据表加一个版本(version)字段，每操作一次，将那条记录的版本号加1。也就是先查询出那条记录，获取出version字段,如果要对那条记录进行操作(更新),则先判断此刻version的值是否与刚刚查询出来时的version的值相等，如果相等，则说明这段期间，没有其他程序对其进行操作，则可以执行更新，将version字段的值加1；如果更新时发现此刻的version值与刚刚获取出来的version的值不相等，则说明这段期间已经有其他程序对其进行操作了，则不进行更新操作。
两种锁各有优缺点，乐观锁适用于写比较少的情况下，即冲突真的很少发生的时候，这样可以省去加锁的开销，加大了系统的整个吞吐量。但如果经常产生冲突，上层应用会不断的进行retry，这样反倒是降低了性能，所以这种情况下用悲观锁就比较合适。
锁的粒度（范围）：是指被封锁目标的大小
锁的粒度和锁的类型都是由SQL Server进行控制的（当然你也可以使用锁提示，但不推荐）。锁会给数据库带来阻塞，因此越大粒度的锁造成更多的阻塞，但由于大粒度的锁需要更少的锁，因此会提升性能。而小粒度的锁由于锁定更少资源，会减少阻塞，因此提高了并发，但同时大量的锁也会造成性能的下降。