-
1、事務的核心就是鎖和并發，優勢是容易理解，劣勢是性能比較低。 性能好，則鎖的顆粒度比較低，增加了編程的難度。需要找到一個平衡。查看全部
-
持久性 事務完成后，該事務對數據庫所做的更改便持久保存在數據庫中 如何保證數據不丟 1.數據丟失原因：物理磁盤損壞，數據從內存寫入磁盤的過程易丟失 2.解決：數據寫入不同的磁盤；提交請求到內存后返回，將內存數據打包到磁盤查看全部
-
快照隔離性：將老版本生成快照，使得讀老版本和寫新版本并行 可針對讀多寫少的優化，能保證一致性的同時實現讀未提交 快照讀可映射到讀未提交和讀已提交 完全無鎖 概念的含混源于定義落后于事物的發展，不是真正意義上對，只是標準 標準不一定是對的查看全部
-
一致性：保證能看到系統內的所有更改 在事務單元運行時將其上鎖，將系統順序化，保證一致性 隔離性：以性能為理由，對一致性的破壞，隔離是為了保證局部一致的前提下提高效率 排它鎖（序列化讀）-讀寫鎖（可重復讀，讀鎖不能被寫鎖升級，只能讀讀并行；讀已提交，讀鎖可以被寫鎖升級；可讀讀，讀寫并行；讀未提交，只加寫鎖，可讀讀，讀寫，寫讀并行，但問題是可能讀到寫過程中得數據） 快照隔離級別-多版本并發控制(MVCC)查看全部
-
單機事務 事務的ACID 原子性：一個事務要么同時成功，要么同時失敗。一旦有某一事務操作出錯，理解為所有操作出錯，回滾到初始狀態查看全部
-
MVCC(multi version concurrency control)：本質是copy on write，做到寫的同時不影響讀，使得讀寫并發，目前的主流。但是系統復雜度變高 事務處理 1.事務單元的先后：利用邏輯時間戳，通過ID號來保證先后 2.故障恢復 a，業務屬性不匹配：利用回滾操作解決 b，系統崩潰：在數據恢復時，進行回滾操作，一直回滾到最初，并且對整個操作上鎖 c，死鎖：兩個線程參與，從不同方向給事務加鎖，并運用相同的資源，就會死鎖。可以進行碰撞檢測（主流），等鎖超時。查看全部
-
事務：鎖和并發的結合體 鎖：為了保證數據庫系統同一時間同一事務只有一個修改而對事務上鎖 越容易理解的模型效率越低，越抽象的模型效率越高 ACID(atomic，constant，isolation，durability)保證事務的完整性 事務單元之間的關系：讀寫，寫讀，讀讀，寫寫 任何對數據庫的操作都可視為事務單元 事務操作方法 1.隊列法：沒有沖突和死鎖，但速度太慢 2.排他鎖：講互斥的事務單元并行處理 3.讀寫鎖：將讀讀和寫寫完全并行，讀寫和寫讀串行，但有可能會影響數據的一致性 讀寫鎖有兩個隔離級別：可重復讀，讀已提交查看全部
-
事務簡介查看全部
-
事務： 鎖 和 并發 的結合體。 --更容易理解 --性能較低 事務簡介： 單個事務單元。 --事務一致性 ACID保證事務完整性（ACID?） 事務單元：建立一個基于GMT_Modified的索引、從數據庫中讀取一行記錄、向數據庫中寫入一行記錄，同時更新這行記錄的所有索引、刪除整張表。。。 一組事務單元（中間狀態？事務單元和事務單元的組合）：事務單元之間的Happen-before關系（讀寫、寫讀、讀讀、寫寫 《事務處理》）；在滿足事務一致性的前提下，如何能夠以最快的速度完成，又能保證上面四種操作的邏輯順序？共享數據的兩個事務單元明顯不能并行。通過讀寫的完全分開，提高讀的性能。 可重復讀（只能做到讀的并行，先讀后寫或先寫后讀都不能并行） 如何實現讀寫并行（提高并行度）， ACID的I就是破壞了一致性。設置不同的隔離級別，打碎原來的一致性。查看全部
-
事物核心就是鎖，并發查看全部
-
保證事務的先后順序，采用SCN（oracle)/Trx_id(MySQL Innodb)實現。查看全部
-
ACID 考究查看全部
-
事務要保證一致性查看全部
-
事務就是鎖和并發的結合查看全部
-
傳統事務下，維護事務一致性:序列化(排隊法、多隊列（加鎖并發讀的讀寫鎖）、multiple version concurrent control(mvcc)（針對寫讀場景、讀讀、讀寫并發高。）)查看全部
舉報
0/150
提交
取消