InnoDB實現序列化隔離級別的方法。本站提示廣大學習愛好者：（InnoDB實現序列化隔離級別的方法）文章只能為提供參考，不一定能成為您想要的結果。以下是InnoDB實現序列化隔離級別的方法正文
序列化的實現
InnoDB對於序列化的實現方式，是通過兩種方式實現的。
第一種，當SELECT語句在一個顯式的事務塊內，如執行表11-9中的編號為1的情況，將施加LOCK_S鎖，根據表11-6（記錄鎖事務鎖相容表）可知，LOCK_S鎖排斥寫鎖，所以序列化隔離級別下只允許並發地讀取操作，並發寫被禁止，因此實現了可序列化。
相應代碼如下：
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語句不在一個顯式的事務塊內，則通過獲取最新快照（在事務開始的時候，），然後讀取數據。此時，因基於快照的一致性讀不需要加鎖，所以其加鎖情況對應到了表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()函數,序列化隔離級別不允許緩沖查詢。
總結
以上就是這篇文章的全部內容了，希望本文的內容對大家的學習或者工作能帶來一定的幫助，如果有疑問大家可以留言交流，謝謝大家對的支持。
