多版本併發控制要解決的問題，其實就是基於可重複讀的情況下，可以在讀的時候不用加鎖，也可以實現可重複讀。
可重複讀的流程如下所示：（小強在讀取b的資訊時候，需要加鎖）
1、假設資料庫中有一張users的表，裡面有如下一行資料：
2、先給這行資料新增兩個隱藏的字段：其中事務id表明這行資料是哪個事務操作的。（事務id是乙個遞增的數字，每次開始新的事務，這個數字就會增加）
3、假如旺財和小強都在操作這行資料，且分別在不同的事務中。
那麼當旺財執行到上圖的第一步的時候，資料是這樣的：
然後，建立乙個叫做read view的資料結構，有如下三個部分：
a、當前活躍的事務列表。此時存在的事務id即【101,102】
b、tmin，活躍事務的最小值，這裡的tmin=101
c、tmax，是系統中最大的事務id加上1，即tmax=103
當進行到第二步的時候，小強執行了乙個update的語句，那麼此時的資料應該是這樣的，此時的回滾指標指向的是上一條記錄。
而此時旺財由於開啟了乙個事務，所以按道理說，雖然小強將age修改為了25，但是旺財應該獲取到的age應該還是20，那麼這個要怎麼實現呢？這裡有乙個演算法，如下所示：
那麼我們根據這個演算法來梳理一下：
旺財走到第一步的時候，首先這條資料的事務id為100.則取出要讀的資料行對應的資料id，賦值給tid。那麼此時tid=100.而tmin為101，所以tid小於tmin，那麼就可以直接去讀了。
當小強對資料做了修改以後，旺財第二次讀的時候，tid=102，因為小強操作的事務id為102，那麼就會走到"tid在readview"這個判斷分支上，而102確實是在活動事務列表中的，所以就順著回滾指標找到下面一行記錄，也就是歷史記錄。
那麼簡而言之，mvcc–多版本併發控制，其實就是不用加鎖，只需要通過演算法去找到正確的版本。這樣讀寫不用互相等待，能極大提高資料庫的併發能力。
讀碼農翻身之TCP IP
這就是三次握手啊，我給你分析一下啊，這三次握手主要是為了驗證我這邊和縣衙那邊的發信 收信能力沒問題，這樣就證明連線是通的，可以正式發貨了。第一次握手 京城發信，縣衙收到了，此時縣衙就會明白 京城發信能力和自己的收信能力是沒問題的。第二次握手 縣衙發信，京城收到了，此時京城就會明白 京城的發信和收信都...
讀碼農翻身之作業系統
1 基本流程 程式首先儲存在硬碟中，當被作業系統裝載後，進入記憶體，然後被cpu執行。2 作業系統裝載程式的流程 a 虛擬記憶體 每個程式可能會認為自己有較大的 如3g 的記憶體，而實際上並不是就分配給了你3g的物理記憶體，而是虛擬記憶體。虛擬記憶體中使用頁表把 在硬碟中的位置記錄下來，等真正需要執...
多版本併發控制（MVCC）
mysql的大多數事務性儲存引擎 如innodb 實現的都不是簡單的行級鎖。基於提公升併發效能的考慮，它們一般都同時實現了多版本併發控制 mvcc 可以認為mvcc是行級鎖的乙個變種，但是它在很多情況下避免了加鎖操作，因此開銷更低。雖然實現機制有所不同，但大都實現了非阻塞的讀操作，寫操作也只鎖定必要...