-
隔離性查看全部
-
快照讀?。?？？?。?？？查看全部
-
隔離級別： 讀已提交，讀鎖可以被寫鎖升級。（讀讀并行，讀寫并行，但是寫讀不能并行） 讀 寫 讀 寫 寫 寫 讀 寫 讀未提交：只加寫鎖，不加讀鎖。（讀讀并行，讀寫并行，寫讀并行） 問題：可能讀到寫過程中的數據。 寫 寫 寫 寫 寫 讀 讀 讀查看全部
-
事務處理 多個事務單元誰先誰后？ 業務屬性不匹配（條件不滿足） 系統崩潰（事務沒有執行結束） 死鎖與死鎖檢測查看全部
-
事務-MVCC 寫讀場景的優化 寫鎖上允許并發讀。查看全部
-
事務的核心：鎖，并發。 事務單元之間的happen-before關系： 讀寫，寫讀，讀讀，寫寫 序列化讀寫： 事務排隊 優化- 排他鎖 （兩個事務兩個隊列） 再優化 - 讀寫鎖 （實現讀并行，讀寫不并行，實現可重復讀） 再優化 - 讀寫鎖 （實現讀并行，讀寫并行，寫鎖取代讀鎖）查看全部
-
事務單元之間的關系查看全部
-
這就是生活查看全部
-
將讀鎖和寫鎖分開定義，讓讀并行，其他的三種方式RW，WR，WW串行查看全部
-
加排它鎖，并行處理無沖突的事務，串行執行有數據沖突的事務查看全部
-
串行方式執行事務查看全部
-
時間戳分為： 邏輯時間戳和 物理時間戳， 邏輯時間戳只用來表示先后關系查看全部
-
Good查看全部
-
單機事務異常應對 回滾 系統down機：進入recovery模式，將提交后的事務單元繼續完成，未提交完成的回滾重新提交 調優原則 減少鎖的覆蓋范圍 增加鎖上可并行的線程數 選擇正確鎖類型：悲觀鎖，使線程到blocking狀態，通知信息ok的狀態切換回等待狀態，缺點是需要數據換入換出，適合并發爭搶嚴重的場景；樂觀鎖，適合并發爭搶不太嚴重的場景查看全部
-
1、多個事務的先后：SCN（oracle），TRX_id（Innodb），通過一個版本號的前后來區分操作的前后，是邏輯時間戳。 2、故障恢復：既是A原子性，事務回滾。當前事務的反向操作。系統崩潰時，在做數據回滾時，數據恢復時，不能讓外部看見你的信息。 3、死鎖與死鎖檢測：產生原因，當三個同時發生時，1、兩個線程2,、不同方向3、相同資源。 4、死鎖的解決方法;1、盡可能不死鎖2、碰撞檢測（通常用這個）（記錄事務鎖的狀態）3、等鎖超時（如果鎖時間超過某個時間，直接拋錯）查看全部
舉報
0/150
提交
取消