下面介绍的是锁的并发问题和解决方法
在实际情况中，通常会因为lock发生四中情况。
下面用个定座系统举例：所有的语句都工作在默认隔离级别下
1 丢失的更新
user1 run
begin tran
select 空座位 得到1，2，3
update 1 定座位1
commit
如果user2在user1 update之前运行同样的程序，都会得到空座位是1,2,3的信息，当然user2也可以定座位1。结果就是user2的定座是最终有效的，user1的定座被覆盖。为了避免这种情况，看看用隔离级别能不能解决。这四种隔离级别最多在表上施加S，由于S是兼容的，因此user2照样能得到空座位是1,2,3的信息，丢失的更新也照样会发生。SQL提供了表级锁定选项TABLOCKX，能避免这种情况的发生，但丧失了并发。
2 脏读
user1 run
begin tran
update row A
commit
如果user2能在user1 update的同时读出表中的数据(包含 row A) 那么就产生了脏读，因为user1可能commit也可能rollback，update并没有被确认。默认情况下是不会产生脏读的，因为update将产生行的X，表的IX，而表IX和S是不兼容的。那么在什么情况下我们需要脏读呢，如果我们不需要确切的数据，我们需要的是一个大概的趋势，个别数据的不确定没有关系，想想一个股票系统，同一时刻的改写会很多，也就是表上会有许多IX锁，如果我们需要查询表获得大致情况，那么只有等改写结束，为了提高并发，此时我们需要脏读。解决方法就是在user2的会话环境中设置事务隔离级别为read uncommitted
3 不可重复读
user1 run
begin tran
select tab1 where
...
...
select tab1 where
commit
当user1在交易中执行两次select，所得到的结果不一样，这便是不可重复读。发生的原因是user2在user1第二次select之前对tab1做了修改。select语句虽然对表有读锁，但在默认情况下，读锁在select语句执行完就被释放，而不是保持到交易结束。为了避免不可重复读的发生，只要select产生的锁保持到交易结束就可以了，将user1的会话环境中设置事务隔离级别为repeatable read
4 幻影
user1 run
begin tran
select tab1 where
...
...
select tab1 where
commit
虽然将user1的会话环境中设置事务隔离级别为repeatable read，但当user1在交易中执行两次select，所得到的结果还会不一样，这便是幻影。因为user1仅仅将select出来的行加了S锁，但user2可以insert满足where条件的新行，使得两次select的结果不一样，解决方法是将user1的会话环境中设置事务隔离级别为serializable,或者在表级锁定选项中选holdlock
锁定超时：
前面说过，当某个语句因为锁而不能立即执行时，会等待，直到锁被释放。但如果持有锁的语句执行时间过长(未优化)。那么就会等待过长，影响响应，因此，我们通过lock_timeout来将等待过长的语句rollback。需要注意的是，当数据量增加时，可能发生不希望的lock_timeout。原因是SQL需要更多的时间来处理数据，为此我们也需要适当的增加lock_timeout。
索引在锁中的应用。
大家都知道索引可以提高查询速度，其实索引还有一个很重要的功能就是提高并发。
例。当user1 run update tab1 set col1=xxx时，user2对tab1 run select * from tab1将会等待，直到user1执行完。但如果user2执行select * from tab1 where col1<>xxx也就是user2要查询的行并不是user1改写的行，结果如何呢？同样，user2也要等到user1执行完.这样就没有什么并发可言。如果我们在col1上建立index，就可以让user2无须等待，立即执行。更常用的是父表和子表的情况，通常为了保证引用完整性，SQL在修改数据时，都会将依赖表加锁，但如果有index，情况就好的多。
