1
SET TRANSACTION ISOLATION LEVEL READ COMMITTED
BEGIN TRANSACTION
UPDATE tb SET
val = val + 10
WHERE id = 2;
WAITFOR DELAY '00:00:07' --模拟事务处理,等待5秒
-- SELECT * FROM tb; --再次SELECT tb表
commit transaction
--ROLLBACK --回滚事务
如果这个时候进行 SELECT * FROM tb where id = 1;的话，那一定得先在id
也就是说在where语句后面至少要有一个（唯一的非聚集索引或聚集索引）,
才会不等待，否则只有等侍第一句SQL完成。
--先创建表:
CREATE TABLE tb(id int,val int)
INSERT tb VALUES(1,10)
INSERT tb VALUES(2,20)
然后在连接1中,执行:
SET TRANSACTION ISOLATION LEVEL READ COMMITTED
BEGIN TRANSACTION
SELECT * FROM tb; --这个SELECT结束后,就会释放掉共享锁
WAITFOR DELAY '00:00:05' --模拟事务处理,等待5秒
SELECT * FROM tb; --再次SELECT tb表
ROLLBACK --回滚事务
在连接2中,执行
UPDATE tb SET
val = val + 10
WHERE id = 2;
--------
回到连接1中.可以看到.两次SELECT的结果是不同的.
因为在默认的READ COMMITTED隔离级别下,SELECT完了.就会马上释放掉共享锁.
--示例2.REPEATABLE READ
连接1:
SET TRANSACTION ISOLATION LEVEL REPEATABLE READ
BEGIN TRANSACTION
SELECT * FROM tb; --这个SELECT结束后,就会释放掉共享锁
WAITFOR DELAY '00:00:05' --模拟事务处理,等待5秒
SELECT * FROM tb; --再次SELECT tb表
ROLLBACK --回滚事务
连接2:
UPDATE tb SET
val = val + 10
WHERE id = 2;
---
可以看到连接2被阻塞了.而且连接1中.两次SELECT的结果是一样的.
因为REPEATABLE READ隔离级别下的共享锁保留到事务结束.
所以别的事务的X锁与S锁不兼容.所以连接2等待.
http://topic.csdn.net/u/20110813/10/cac77918-667e-483f-b819-7bfe9e058097.html 索引与死锁的关系
3 tablock , rowlock 之类的要放在事务中才起作用。
READ COMMITTED 读，读完马上释放， 可以读写， 写，1 如果有用到索引，如果还是那行，则会等待，
2 如果没有用到索引， 不管怎么样，另外一个连接都不可以读，
但使用nolock均可以读。
REPEATABLE READ 读，会行锁（如果where中没有索引），如果另外一个语句也读，则会等待，
因为REPEATABLE READ隔离级别下的共享锁保留到事务结束.