数据库隔离级别测试（sqlserver2008）

今天上班干完事无聊的对数据库的四种隔离级别做了测试测试报告如下

数据库的隔离级别测试开的两个窗口

Read uncommitted 读未提交

first:

use mydemo

go

 

set transaction isolation level READ unCOMMITTED

 

begin transaction

select COUNT(*) from stu----------------------------答案是10

 

 

second:

use mydemo

go

 

set transaction isolation level READ unCOMMITTED

 

begin transaction

insert  into stu(姓名) values('1');------------------------------这时候只执行了蓝色的代码并没有提交

 

thirld:

select COUNT(*) from stu---这时候再在另外一个界面执行红框代码答案是11

 

 

这时候就出现了第二个事务只是执行了但是并没有提交的数据被另外一个事务查询到了。。。出现了脏读，假如insert的事务要是出错回滚，那么第二次读取的11就不是真正的数据就属于脏读取。

Read committed 读已经提交

数据库的隔离级别设置成这样可以防止脏读（即读取了别人没提交的数据）但是不可以防止重复读取，还原之前的数据测试Read committed

first

use mydemo

go

 

set transaction isolation level READ COMMITTED

 

begin transaction

select COUNT(*) from stu----------------------------答案是10

 

second:

use mydemo

go

 

set transaction isolation level READ COMMITTED

 

begin transaction

insert  into stu(姓名) values('1');------------------------------这时候只执行了蓝色的代码并没有提交

 

thirld:

select COUNT(*) from stu---再去执行蓝色的时候可以看到卡在那点一直都没有查询出来

 

 

这时候再去前面的窗口把数据commit后

 

刚才卡住一直在查询的界面有数据了并且是提交后修改的数据11

 

结论证明这种可以防止读取别人还没有提交的数据，必须是已经提交了才能读取

 

 

Repeatable read 重复读

可以解决脏读和不可重复读取，测试还原数据库数据测试Repeatable read 重复读

还是那个例子

first:

use mydemo

go

 

set transaction isolation level Repeatable read

 

begin transaction

select COUNT(*) from stu----------------------------答案是10

 

 

second:

换另外一个界面执行insert

begin transaction

insert  into stu(姓名) values('1');

 

这时候就会发现和Read committed 读已经提交的结果是一样的，如果不commit之前的事务再去查询是会卡在界面的。等这个commit后查询结果出来了。

select COUNT(*) from stu

 

 

等再去执行commit的时候也就是这个

commit

 

回过来看刚才的查询发现查询结果由原来的卡住变成有结果了

 

 

那Repeatable read比Read committed多了什么呢那就是update的时候

还是那个例子换一种测试方法使用update去测试

执行语句

use mydemo

go

 

set transaction isolation level Repeatable read

begin transaction

select * from stu----------------------执行蓝色语句单不提交

 

 

然后换窗口执行蓝色语句

use mydemo

go

 

set transaction isolation level Repeatable read

 

begin transaction

update stu set 姓名='2'------------------这时候发现卡住了执行更新就卡住了

 

 

然后回过头把之前的查询的事务提交了

 

换窗口一看

之前卡住的更新已经执行成功了。

 

更新后如果不提交发现后面再查也是查不到的然后执行更新后commit再去查询

select * from stu

 

 

这时候发现数据已经变了。

总结Repeatable read这种隔离级别可以让让一个事务在读取数据的时候防止另外一个事务去去修改update这个数据从而达到不可重读，也就是在我读这个数据的时候我读的事务没有提交那么其他的事务就不能修改这个数据（相当于锁行）

SERIALIZABLE （串行化事务这个表示只要开启了一个事务那么另外一个事务都不能操作数据测了下只针对（增，删，改））这个相当于锁表了。除了读取其他都不能干

这个很容易测试就不给例子了（我测试过很多只要开启了事务那么另外一个界面不管你怎么弄(除了读)都会卡住直到之前的事务提交或者回滚）