資源描述：
《高可用性、負(fù)載均衡mysql集群解決方案》由會(huì)員上傳分享，免費(fèi)在線閱讀，更多相關(guān)內(nèi)容在行業(yè)資料-天天文庫(kù)。
1、數(shù)據(jù)庫(kù)弱一致性四個(gè)隔離級(jí)別SQL-92標(biāo)準(zhǔn)中定義了四個(gè)隔離級(jí)別，這四個(gè)隔離級(jí)別在以前版本的SQLServer中即受到支持：READUNCOMMITTEDREADUNCOMMITTED是限制性最弱的隔離級(jí)別，因?yàn)樵摷?jí)別忽略其他事務(wù)放置的鎖。使用READUNCOMMITTED級(jí)別執(zhí)行的事務(wù)，可以讀取尚未由其他事務(wù)提交的修改后的數(shù)據(jù)值，這些行為稱為“臟”讀。這是因?yàn)樵赗eadUncommitted級(jí)別下，讀取數(shù)據(jù)不需要加S鎖，這樣就不會(huì)跟被修改的數(shù)據(jù)上的X鎖沖突。比如，事務(wù)1修改一行，事務(wù)2在事務(wù)1提交之前讀取了這一行。如果
2、事務(wù)1回滾，事務(wù)2就讀取了一行沒(méi)有提交的數(shù)據(jù)，這樣的數(shù)據(jù)我們認(rèn)為是不存在的。READCOMMITTEDREADCOMMITTED(Nonrepeatablereads)是SQLServer默認(rèn)的隔離級(jí)別。該級(jí)別通過(guò)指定語(yǔ)句不能讀取其他事務(wù)已修改但是尚未提交的數(shù)據(jù)值，禁止執(zhí)行臟讀。在當(dāng)前事務(wù)中的各個(gè)語(yǔ)句執(zhí)行之間，其他事務(wù)仍可以修改、插入或刪除數(shù)據(jù)，從而產(chǎn)生無(wú)法重復(fù)的讀操作，或“影子”數(shù)據(jù)。比如，事務(wù)1讀取了一行，事務(wù)2修改或者刪除這一行并且提交。如果事務(wù)1想再一次讀取這一行，它將獲得修改后的數(shù)據(jù)或者發(fā)現(xiàn)這一樣已經(jīng)被刪除，
3、因此事務(wù)的第二次讀取結(jié)果與第一次讀取結(jié)果不同，因此也叫不可重復(fù)讀。實(shí)驗(yàn)1query1：事務(wù)1--step1:創(chuàng)建實(shí)驗(yàn)數(shù)據(jù)select*intoEmployeefromAdventureWorks.HumanResources.EmployeealtertableEmployeeaddconstraintpk_Employee_EmployeeIDprimarykey(EmployeeID)--step2:設(shè)置隔離級(jí)別,這是數(shù)據(jù)庫(kù)的默認(rèn)隔離界別SETTRANSACTIONISOLATIONLEVELREADCOMMITT
4、ED--step3:開(kāi)啟第一個(gè)事務(wù)BEGINTRANtran1--step4:執(zhí)行select操作,查看VacationHours,對(duì)查找的記錄加S鎖，在語(yǔ)句執(zhí)行完以后自動(dòng)釋放S鎖SELECTEmployeeID,VacationHoursFROMEmployeeWHEREEmployeeID=4;--step5:查看當(dāng)前加鎖情況,沒(méi)有發(fā)現(xiàn)在Employee表上面有鎖,這是因?yàn)楫?dāng)前的隔離界別是READCOMMITTED--在執(zhí)行完step2以后馬上釋放了S鎖.SELECTrequest_session_id,resou
5、rce_type,resource_associated_entity_id,request_status,request_mode,resource_descriptionFROMsys.dm_tran_locks查看鎖的情況如下圖所示，我們發(fā)現(xiàn)在只有在數(shù)據(jù)庫(kù)級(jí)別的S鎖，而沒(méi)有在表級(jí)別或者更低級(jí)別的鎖，這是因?yàn)樵赗eadCommitted級(jí)別下，S鎖在語(yǔ)句執(zhí)行完以后就被釋放。query2：事務(wù)2--step6:開(kāi)啟第二個(gè)事務(wù)BEGINTRANtran2;--step7:修改VacationHours,需要獲得排它鎖X
6、,在VacationHours上沒(méi)有有S鎖UPDATEEmployeeSETVacationHours=VacationHours-8WHEREEmployeeID=4;--step8:查看當(dāng)前加鎖情況SELECTrequest_session_id,resource_type,resource_associated_entity_id,request_status,request_mode,resource_descriptionFROMsys.dm_tran_locks在開(kāi)啟另外一個(gè)update事務(wù)以后，我們?cè)偃ゲ?/p>
7、看當(dāng)前的鎖狀況，如下圖所示，我們發(fā)現(xiàn)在表(Object)級(jí)別上加了IX鎖，在這張表所在的Page上也加了IX鎖，因?yàn)楸砑恿司奂饕栽谌~子結(jié)點(diǎn)上加了X鎖，這個(gè)鎖的類型是KEY。然后我們回到事務(wù)1當(dāng)中再次執(zhí)行查詢語(yǔ)句，我們會(huì)發(fā)現(xiàn)查詢被阻塞，我們新建一個(gè)查詢query3來(lái)查看這個(gè)時(shí)候的鎖狀況，其查詢結(jié)果如下，我們可以發(fā)現(xiàn)查詢操作需要在KEY級(jí)別上申請(qǐng)S鎖，在Page和表(Object)上面申請(qǐng)IS鎖，但是因?yàn)镵ey上面原先有了X鎖，與當(dāng)前讀操作申請(qǐng)的S鎖沖突，所以這一步處于WAIT狀態(tài)。如果此時(shí)提交事務(wù)2的update
8、操作，那么事務(wù)1的select操作不再被阻塞，得到查詢結(jié)果，但是我們發(fā)現(xiàn)此時(shí)得到的查詢結(jié)果與第一次得到的查詢結(jié)果不同，這也是為什么將readcommitted稱為不可重復(fù)讀，因?yàn)橥粋€(gè)事物內(nèi)的兩次相同的查詢操作的結(jié)果可能不同。REPEATABLEREADREPEATABLEREAD是比READCOMMITTED限制性更強(qiáng)的隔離級(jí)別
