序列化的實現(xiàn)
InnoDB對于序列化的實現(xiàn)方式，是通過兩種方式實現(xiàn)的。
第一種，當SELECT語句在一個顯式的事務塊內，如執(zhí)行表11-9中的編號為1的情況，將施加LOCK_S鎖，根據表11-6（記錄鎖事務鎖相容表）可知，LOCK_S鎖排斥寫鎖，所以序列化隔離級別下只允許并發(fā)地讀取操作，并發(fā)寫被禁止，因此實現(xiàn)了可序列化。
相應代碼如下：
ha_innobase::external_lock(...)
{...
if (lock_type != F_UNLCK) {
/* MySQL is setting a new table lock */
...
if (trx->isolation_level == TRX_ISO_SERIALIZABLE //序列化隔離級別
m_prebuilt->select_lock_type == LOCK_NONE
thd_test_options(thd, OPTION_NOT_AUTOCOMMIT | OPTION_BEGIN)) { //且在一個顯式事務塊內部
/* To get serializable execution, we let InnoDB conceptually add 'LOCK IN SHARE MODE' to all SELECTs
which otherwise would have been consistent reads. An exception is consistent reads in the AUTOCOMMIT=1 mode:
we know that they are read-only transactions, and they can be serialized also if performed as consistent reads. */
m_prebuilt->select_lock_type = LOCK_S; //加讀鎖，即 'LOCK IN SHARE MODE'
m_prebuilt->stored_select_lock_type = LOCK_S;
} //否則，不加鎖（這一點也很重要）
...
} else {
TrxInInnoDB::end_stmt(trx);
DEBUG_SYNC_C("ha_innobase_end_statement");
}
...}
第二種，當SELECT語句不在一個顯式的事務塊內，則通過獲取最新快照（在事務開始的時候，），然后讀取數(shù)據。此時，因基于快照的一致性讀不需要加鎖，所以其加鎖情況對應到了表11-9中的編號2對應的情況。
表11-9 序列化隔離級別加鎖情況
說明：
S0：SELECT * FROM bluesea WHERE c1=2; //使用主鍵索引做WHERE條件
另外，對于FLUSH...WITH READ LOCK語句，序列化隔離級別下也需要加讀鎖LOCK_S
代碼如下：
ha_innobase::store_lock(
...
/* Check for FLUSH TABLES ... WITH READ LOCK */
if (trx->isolation_level == TRX_ISO_SERIALIZABLE) {
m_prebuilt->select_lock_type = LOCK_S;
m_prebuilt->stored_select_lock_type = LOCK_S;
} else {
m_prebuilt->select_lock_type = LOCK_NONE;
m_prebuilt->stored_select_lock_type = LOCK_NONE;
}
...
}
與序列化相關的，還有innobase_query_caching_of_table_permitted()函數(shù),序列化隔離級別不允許緩沖查詢。
總結
以上就是這篇文章的全部內容了，希望本文的內容對大家的學習或者工作能帶來一定的幫助，如果有疑問大家可以留言交流，謝謝大家對腳本之家的支持。
您可能感興趣的文章:- MySQL中Innodb的事務隔離級別和鎖的關系的講解教程
- 淺談InnoDB隔離模式的使用對MySQL性能造成的影響
