高可用性负载均衡的mysql集群解决方案.docxVIP

数据库弱一致性四个隔离级别SQL-92标准中定义了四个隔离级别，这四个隔离级别在以前版本的SQL Server中即受到支持：READ UNCOMMITTEDREAD UNCOMMITTED是限制性最弱的隔离级别，因为该级别忽略其他事务放置的锁。使用READ UNCOMMITTED级别执行的事务，可以读取尚未由其他事务提交的修改后的数据值，这些行为称为“脏”读。这是因为在Read Uncommitted级别下，读取数据不需要加S锁，这样就不会跟被修改的数据上的X锁冲突。比如，事务1修改一行，事务2在事务1提交之前读取了这一行。如果事务1回滚，事务2就读取了一行没有提交的数据，这样的数据我们认为是不存在的。READ COMMITTEDREAD COMMITTED(Nonrepeatable reads)是SQL Server默认的隔离级别。该级别通过指定语句不能读取其他事务已修改但是尚未提交的数据值，禁止执行脏读。在当前事务中的各个语句执行之间，其他事务仍可以修改、插入或删除数据，从而产生无法重复的读操作，或“影子”数据。比如，事务1读取了一行，事务2修改或者删除这一行并且提交。如果事务1想再一次读取这一行，它将获得修改后的数据或者发现这一样已经被删除，因此事务的第二次读取结果与第一次读取结果不同，因此也叫不可重复读。实验1query1：事务1--step1:创建实验数据select * into Employee from AdventureWorks.HumanResources.Employeealter table Employee add constraint pk_Employee_EmployeeID primary key(EmployeeID)--step2:设置隔离级别,这是数据库的默认隔离界别SET TRANSACTION ISOLATION LEVEL READ COMMITTED--step3:开启第一个事务BEGIN TRAN tran1 --step4:执行select操作,查看VacationHours,对查找的记录加S锁，在语句执行完以后自动释放S锁 SELECT EmployeeID, VacationHours FROM Employee WHERE EmployeeID = 4; --step5:查看当前加锁情况,没有发现在Employee表上面有锁,这是因为当前的隔离界别是READ COMMITTED --在执行完step2以后马上释放了S锁. SELECT request_session_id, resource_type, resource_associated_entity_id, request_status, request_mode, resource_description FROM sys.dm_tran_locks查看锁的情况如下图所示，我们发现在只有在数据库级别的S锁，而没有在表级别或者更低级别的锁，这是因为在Read Committed级别下，S锁在语句执行完以后就被释放。query2：事务2--step6:开启第二个事务BEGIN TRAN tran2; --step7:修改VacationHours,需要获得排它锁X,在VacationHours上没有有S锁 UPDATE Employee SET VacationHours = VacationHours - 8 WHERE EmployeeID = 4; --step8:查看当前加锁情况 SELECT request_session_id, resource_type, resource_associated_entity_id, request_status, request_mode, resource_description FROM sys.dm_tran_locks在开启另外一个update事务以后，我们再去查看当前的锁状况，如下图所示，我们发现在表(Object)级别上加了IX锁，在这张表所在的Page上也加了IX锁，因为表加了聚集索引，所以在叶子结点上加了X锁，这个锁的类型是KEY。然后我们回到事务1当中再次执行查询语句，我们会发现查询被阻塞，我们新建一个查询query3来查看这个时候的锁状况，其查询结果如下，我们可以发现查询操作需要在KEY级别上申请S锁，在Page和表(Object)上面申请IS锁，但是因为Key上面原先有了X锁，与当前读操作申请的S锁冲突，所以这一步处于WAIT状态。如果此时提交事务2的update操作，那么事务1的select操作不再被阻塞，得到查询结果，但是我们发现此时得到的查询结果与第一次得到的查询结果不同，这也是为什么将read committed称为不可重复读