InnoDB 的 isolation mode

Percona 老大 Peter Zaitsev 寫了一篇關於 InnoDB 的 isolation mode 與效能的關係:「MySQL performance implications of InnoDB isolation modes」。

關於 isolation level 的介紹,也可以參考維基百科上的說明:「Isolation (database systems)」。

其中有個我也認同的的建議:

In general I think good practice is to use READ COMITTED isolation mode as default and change to REPEATABLE READ for those applications or transactions which require it.

需要 REPEATABLE READ 需求的 transaction 可以在 session 裡面開,不需要平常就開著。

而剛從 MyISAM 轉過去的因為本來就沒有 transaction,換到 InnoDB 時強烈建議就直接設上去 (剛好在註解也有提到):

I think READ-COMMITTED is better default yet it can break some applications. Though so changing to default storage engine from MyISAM to Innodb did.

MySQL InnoDB 遇到 Deadlock 時的判讀

Percona 的「How to deal with MySQL deadlocks」這篇文章裡面提到了 MySQL InnoDB Deadlock 的判讀與處理。

在支援 transaction 的 engine 裡 deadlock 是不可避免的常態。

在 MySQL 5.5 以及之前的版本,可以透過 Percona 的 pt-deadlock-logger 這隻 script,每固定幾秒鐘就跑一次 SHOW ENGINE INNODB STATUS 記錄下來。在 MySQL 5.6 之後,可以直接使用 innodb_print_all_deadlocks 這個參數,遇到 deadlock 時就寫到 error log 裡。

有了 log 後,接下來就可以判讀 deadlock 的情況,得知是什麼樣的情況造成 deadlock。

文章最後面則是對減少 deadlock 的方法給了一些建議,都是比較一般性。一般還是要靠 bussiness logic 的分析來切割降低 deadlock 的情況。

不過這篇文章需要一些背景知識,像是 InnoDB Lock Modes 與維基百科上的「Multiple granularity locking」,對解讀會有更多幫助。