mysql下的事務一致性怎麼解釋

1樓：匿名使用者

你好：說白了就是要不都提交成功，要不就都直接回滾。一般都是遇到exception；

如果事物提交後，那麼只能回滾未提交的。

2樓：愛可生雲資料庫

用 pt-table-checksum 時，會不會影響業務效能？

實驗我們先建一對主從：

然後用 mysqlslap跑乙個持續的壓力：

開另外乙個會話，將 master 上的 general log 開啟：

然後通過 pt-table-checksum 進行一次比較：

檢視 master 的 general log，由於 mysqlslap 的影響，general log 中有很多內容，我們找到與 pt-table-checksum 相關的執行緒：

將該執行緒的操作單獨列出來：

操作比較多，我們一點一點來說明：

這裡工具調小了 innodb 鎖等待時間。使得之後的操作，只要在 innodb 上稍微有鎖等待，就會馬上放棄操作，對業務影響很小。

另外工具調小了 wait_timeout 時間，倒是沒有特別的作用。

工具將隔離級別調整為了 rr 級別，事務的維護代價會比 rc 要高，不過後面我們會看到工具使用的每個事務都很小，加上之前提到 innodb 鎖等待時間調到很小，對線上業務產生的成本比較小。

rr 級別是資料對比的基本要求。

工具通過一系列操作，了解表的概況。工具是乙個資料塊乙個資料塊進行校驗，這裡獲取了第乙個資料塊的下邊界。

接下來工具獲取了下乙個資料塊的下邊界，每個 sql前都會 explain 一下，看一下執行成本，非常小心翼翼。

之後工具獲取了乙個資料塊的 checksum，這個資料塊不大，如果跟業務流量有衝突，會馬上出發 innodb 的鎖超時，立刻退讓。

以上是 pt-table-checksum 的一些設計，可以看到這幾處都是精心維護了業務流量不受影響。

工具還設計了其他的一些機制保障業務流量，比如引數 --max-load 和 --pause-file 等，還有精心設計的資料塊劃分方法，索引選擇方法等。大家根據自己的情況配合使用即可達到很好的效果。

總結本期我們介紹了簡單分析 pt-table-checksum 是否會影響業務流量，坊間會流傳工具的各種引數建議或者不建議使用，算命的情況比較多，大家都可以用簡單的實驗來分析其中機制。

還是那個觀點，效能測試不能相信道聽途說，得通過實驗去分析。

怎樣理解mysql中的一致性

3樓：折柳成萌

定義：資料庫一致性（database consistency）是指事務執行的結果必須是使資料庫從乙個一致性狀態變到另乙個一致性狀態。

資料庫狀態如何變化？每一次資料變更就會導致資料庫的狀態遷移。如果資料庫的初始狀態是c0，第一次事務t1的提交就會導致系統生成乙個system change number（scn），這是資料庫狀態從c0轉變成c1。

執行第二個事務t2的時候資料庫狀態從t1變成t2，以此類推，執行第tn次事務的時候資料庫狀態由c(n-1)變成cn。

定義一致性主要有2個方面，一致讀和一致寫。

一致寫：事務執行的資料變更只能基於上乙個一致的狀態，且只能體現在乙個狀態中。t(n)的變更結果只能基於c(n-1)，c(n-2), ...

c(1)狀態，且只能體現在c(n)狀態中。也就是說，乙個狀態只能有乙個事務變更資料，不允許有2個或者2個以上事務在乙個狀態中變更資料。至於具體一致寫基於哪個狀態，需要判斷t(n)事務是否和t(n-1)，t(n-2),...

t(1)有依賴關係。

一致讀：事務讀取資料只能從乙個狀態中讀取，不能從2個或者2個以上狀態讀取。也就是t(n)只能從c(n-1），c(n-2)...

c(1)中的乙個狀態讀取資料，不能一部分資料讀取自c(n-1)，而另一部分資料讀取自c(n-2)。