簡單背景介紹

MySQL

MySQL是現在最流行的關系型數據庫(RDB)的選擇, 創建一個應用時，無論是用戶數據還是訂單數據，使用關系型數據庫存儲是最可靠穩定的選擇，借助RDB提供的可靠性、事務等功能，為應用提供完善的支持。MySQL是開源軟件，可以免費使用，MySQL在發展多年后越來越成熟，成為大部分公司的數據庫首選。MySQL采用插件式的存儲引擎架構，5.5版本后默認使用InnoDB存儲引擎。

MySQL架構

MySQL從概念上可以分為四層，頂層是接入層，不同語言的客戶端通過mysql的協議與mysql服務器進行連接通信，接入層進行權限驗證、連接池管理、線程管理等。下面是mysql服務層，包括sql解析器、sql優化器、數據緩沖、緩存等。再下面是mysql中的存儲引擎層，mysql中存儲引擎是基于表的。最后是系統文件層，保存數據、索引、日志等。

MVCC

MVCC是Multi Version Concurrency Control的簡稱，代表多版本并發控制。為什么需要MVCC，還要從數據庫事務的ACID特性說起。

相信很多朋友都了解ACID，它們分別代表了Atomicity(原子性), Consistency(一致性), Isolation(隔離性), Durability(持久性)。

原子性表示一個事務的操作結果要么全部執行要么全部不執行。

一致性表示事務總是從一個一致的狀態轉換到另一個一致的狀態。

隔離性表示一個事務的修改結果在什么時間能夠被其他事務看到，SQL1992規范中對隔離性定義了不同的隔離級別，

分為讀未提交(READ UNCOMMITED),事務能夠看到其他事務沒有提及的修改，當另一個事務又回滾了修改后的情況又被稱為臟讀dirty read。

讀已提交(READ COMMITTED),事務能夠看到其他事務提交后的修改，這時會出現一個事務內兩次讀取數據可能因為其他事務提交的修改導致不一致的情況，稱為不可重復讀。 可重復讀(REPEATABLE READ)，在兩次讀取時讀取到的數據的狀態是一致的，和序列化(SERIALIZABLE)可重復讀中可能出現第二次讀讀到第一次沒有讀到的數據，也就是被其他事務插入的數據，這種情況稱為幻讀phantom read, 序列化級別中不能出現幻讀。

隔離級別依次增強，但是導致的問題是并發能力的減弱。

各種數據庫廠商會對各個隔離級別進行實現。

和Java中的多線程問題相同，數據庫通常使用鎖來實現隔離性。

最原生的鎖，鎖住一個資源后會禁止其他任何線程訪問同一個資源。但是很多應用的一個特點都是讀多寫少的場景，很多數據的讀取次數遠大于修改的次數，而讀取數據間互相排斥顯得不是很必要。所以就使用了一種讀寫鎖的方法，讀鎖和讀鎖之間不互斥，而寫鎖和寫鎖、讀鎖都互斥。這樣就很大提升了系統的并發能力。之后人們發現并發讀還是不夠，又提出了能不能讓讀寫之間也不沖突的方法，就是讀取數據時通過一種類似快照的方式將數據保存下來，這樣讀鎖就和寫鎖不沖突了，不同的事務session會看到自己特定版本的數據。當然快照是一種概念模型，不同的數據庫可能用不同的方式來實現這種功能。

之后的討論默認均以REPEATABLE READ作為隔離級別。

InnoDB與MVCC

MySQL中的InnoDB存儲引擎的特性有，默認隔離級別REPEATABLE READ, 行級鎖，實現了MVCC, Consistent nonlocking read(默認讀不加鎖，一致性非鎖定讀), Insert Buffer, Adaptive Hash Index, DoubleWrite, Cluster Index。

上面列舉了這么多，表示InnoDB有很多特性、很快。

InnoDB中通過UndoLog實現了數據的多版本，而并發控制通過鎖來實現。

Undo Log除了實現MVCC外，還用于事務的回滾。

Redo log, bin log, Undo log

MySQL Innodb中存在多種日志，除了錯誤日志、查詢日志外，還有很多和數據持久性、一致性有關的日志。

binlog，是mysql服務層產生的日志，常用來進行數據恢復、數據庫復制，常見的mysql主從架構，就是采用slave同步master的binlog實現的, 另外通過解析binlog能夠實現mysql到其他數據源(如ElasticSearch)的數據復制。

redo log記錄了數據操作在物理層面的修改，mysql中使用了大量緩存，緩存存在于內存中，修改操作時會直接修改內存，而不是立刻修改磁盤，當內存和磁盤的數據不一致時，稱內存中的數據為臟頁(dirty page)。為了保證數據的安全性，事務進行中時會不斷的產生redo log，在事務提交時進行一次flush操作，保存到磁盤中, redo log是按照順序寫入的，磁盤的順序讀寫的速度遠大于隨機讀寫。當數據庫或主機失效重啟時，會根據redo log進行數據的恢復，如果redo log中有事務提交，則進行事務提交修改數據。這樣實現了事務的原子性、一致性和持久性。

Undo Log: 除了記錄redo log外，當進行數據修改時還會記錄undo log，undo log用于數據的撤回操作，它記錄了修改的反向操作，比如，插入對應刪除，修改對應修改為原來的數據，通過undo log可以實現事務回滾，并且可以根據undo log回溯到某個特定的版本的數據，實現MVCC。

redo log 和binlog的一致性，為了防止寫完binlog但是redo log的事務還沒提交導致的不一致，innodb 使用了兩階段提交

大致執行序列為

InnoDB prepare (持有prepare_commit_mutex)；

write/sync Binlog；

InnoDB commit (寫入COMMIT標記后釋放prepare_commit_mutex)。

MVCC實現

innodb中通過B+樹作為索引的數據結構，并且主鍵所在的索引為ClusterIndex(聚簇索引), ClusterIndex中的葉子節點中保存了對應的數據內容。一個表只能有一個主鍵，所以只能有一個聚簇索引，如果表沒有定義主鍵，則選擇第一個非NULL唯一索引作為聚簇索引，如果還沒有則生成一個隱藏id列作為聚簇索引。

除了Cluster Index外的索引是Secondary Index(輔助索引)。輔助索引中的葉子節點保存的是聚簇索引的葉子節點的值。

InnoDB行記錄中除了剛才提到的rowid外，還有trx_id和db_roll_ptr, trx_id表示最近修改的事務的id,db_roll_ptr指向undo segment中的undo log。

新增一個事務時事務id會增加，trx_id能夠表示事務開始的先后順序。

Undo log分為Insert和Update兩種，delete可以看做是一種特殊的update，即在記錄上修改刪除標記。

update undo log記錄了數據之前的數據信息，通過這些信息可以還原到之前版本的狀態。

當進行插入操作時，生成的Insert undo log在事務提交后即可刪除，因為其他事務不需要這個undo log。

進行刪除修改操作時，會生成對應的undo log，并將當前數據記錄中的db_roll_ptr指向新的undo log

數據可見性判斷

CREATE TABLE `testunique` (

`id` int(11) unsigned NOT NULL AUTO_INCREMENT,

`uid` int(11) DEFAULT NULL,

`ukey` int(11) DEFAULT NULL,

PRIMARY KEY (`id`),

KEY `id_uid` (`uid`),

KEY `index_key` (`ukey`)

) ENGINE=InnoDB AUTO_INCREMENT=70 DEFAULT CHARSET=utf8;

隔離級別REPEATABLE READ

只有當session2 commit之后的查詢才能查到session1插入的數據

事務可見性的處理過程:

RR級別下一個事務開始后第一個snapshot read的時候，會將當期活動的事務id記錄下來，記錄到read view中。RC級別則是每次snapshot read都會創建一個新的read view。

假設當前,read view中最大的事務id為tmax, 最小為tmin。則判斷一個數據是否可見以及對應的版本的方法為。

如果該行中的trx_id, 賦值給tid, 如果tid和當前事務id相等或小于tmin，說明是事務內發生的或開啟前的修改，則直接返回該版本數據; 如果

trx_id大于tmax, 則查看該版本的db_roll_ptr中的trx_id，賦值給tid并從頭開始判斷。如果tid小于tmax并且不在read view中，則返回，否則中回滾段中找出undo log的trx_id，賦值給tid從頭判斷。

所以可見性是，只有當第一次讀之前提交的修改和自己的修改可見，其他的均不可見。

代碼實現部分

在storage/innobase/include/read0types.h中

// Friend declaration

class MVCC;

/** Read view lists the trx ids of those transactions for which a consistent

read should not see the modifications to the database. */

...

class ReadView {

...

private:

// Prevent copying

ids_t(const ids_t&);

ids_t& operator=(const ids_t&);

private:

/** Memory for the array */

value_type* m_ptr;

/** Number of active elements in the array */

ulint m_size;

/** Size of m_ptr in elements */

ulint m_reserved;

friend class ReadView;

};

public:

ReadView();

~ReadView();

/** Check whether transaction id is valid.

@param[in] id transaction id to check

@param[in] name table name */

static void check_trx_id_sanity(

trx_id_t id,

const table_name_t& name);

// 判斷一個修改是否可見

/** Check whether the changes by id are visible.

@param[in] id transaction id to check against the view

@param[in] name table name

@return whether the view sees the modifications of id. */

bool changes_visible(

trx_id_t id,

const table_name_t& name) const

MY_ATTRIBUTE((warn_unused_result))

{

ut_ad(id > 0);

if (id < m_up_limit_id || id == m_creator_trx_id) {

return(true);

}

check_trx_id_sanity(id, name);

if (id >= m_low_limit_id) {

return(false);

} else if (m_ids.empty()) {

return(true);

}

const ids_t::value_type* p = m_ids.data();

return(!std::binary_search(p, p + m_ids.size(), id));

}

private:

// Disable copying

ReadView(const ReadView&);

ReadView& operator=(const ReadView&);

private:

// 活動事務中的id的最大

/** The read should not see any transaction with trx id >= this

value. In other words, this is the "high water mark". */

trx_id_t m_low_limit_id;

// 活動事務id的最小值

/** The read should see all trx ids which are strictly

smaller (

low water mark". */

//

trx_id_t m_up_limit_id;

/** trx id of creating transaction, set to TRX_ID_MAX for free

views. */

trx_id_t m_creator_trx_id;

/** Set of RW transactions that was active when this snapshot

was taken */

ids_t m_ids;

/** The view does not need to see the undo logs for transactions

whose transaction number is strictly smaller (

they can be removed in purge if not needed by other views */

trx_id_t m_low_limit_no;

/** AC-NL-RO transaction view that has been "closed". */

bool m_closed;

typedef UT_LIST_NODE_T(ReadView) node_t;

/** List of read views in trx_sys */

byte pad1[64 - sizeof(node_t)];

node_t m_view_list;

};

Undo log刪除

undo log在沒有活動事務依賴(用于consistent read或回滾)便可以清楚，innodb 中存在后臺purge 線程進行后臺輪詢刪除undo log。

Current Read snapshot read

REPEATABLE READ隔離級別下普通的讀操作即select都不加鎖，使用MVCC進行一致性讀取，這種讀取又叫做snapshot read。

而update, insert, delete, select … for update, select … lock in share mode都會進行加鎖，并且讀取的是當前版本，也就是READ COMMITTED讀的效果。innodb-locks-set.html中對各種操作會進行的鎖操作有詳細的說明，這里我簡單總結下。

InnoDB中加鎖的方法是鎖住對應的索引，一個操作進行前會選擇一個索引進行掃描，掃描到一行后加上對應的鎖然后返回給上層然后繼續掃描。InnoDB支持行級鎖(record lock)，上述需要加鎖的操作中，除了select … lock in share mode 是加shared lock(共享鎖或讀鎖)外其他操作都加的是exclusive lock(即排他鎖或寫鎖)。在加行級鎖前，會對表加一個intention lock，即意向鎖，意向所是表級鎖，不會和行級鎖沖突，主要用途是表明一個要加行級鎖或正在加鎖的操作。

另外InnoDB種除了record lock外還有一種gap lock，即鎖住兩個記錄間的間隙，防止其他事務插入數據，用于防止幻讀。當索引是主鍵索引或唯一索引時，不需要加gap lock。當索引不是唯一索引時，需要對索引數據和索引前的gap加鎖，這種方式叫做next-key locking。

另外在插入數據時，還需要提前最插入行的前面部分加上insert intention lock, 即插入意向鎖，插入意向鎖之間不會沖突，會和gap鎖沖突導致等待。當插入時遇到duplicated key錯誤時，會在要插入的行上加上share lock。

參考

• https://dev.mysql.com/doc/refman/5.7/en/innodb-storage-engine.html
• http://hedengcheng.com/
• MySQL技術內幕
• http://www.postgres.cn/downfiles/pg2016conf_day2_s1_pm3.pdf
• https://dev.mysql.com/doc/refman/5.7/en/source-installation.html
• https://blog.jcole.us/2014/04/16/the-basics-of-the-innodb-undo-logging-and-history-system/
• http://www.cnblogs.com/chenpingzhao/p/5065316.html

總結

以上是生活随笔為你收集整理的window.open 实现session隔离_InnoDB存储引擎MVCC实现原理的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。