當事務遇到了IO

此讨論僅限于Innodb存儲引擎；

DBA與研發人員溝通的時候常常會說 “拒絕大事務，這事務太大啦，拆開”，“你要批量送出”；“什麼，批量送出？這豈不是成了一個大事務？”

我根據自己的了解簡單說明下,拒絕大事務，批量送出是針對不同“場景”的；

大事務就意味着鎖持有的時間比較長（盡管Innodb是行鎖）：

缺點:

1、造成鎖等待，其他需要同樣row的事務處于lock wait狀态，加大響應時間；

2、對一張表并發較高的時候，造成死鎖幾率較高

3、對于replication環境，會造成slave延遲較高（單線程SQL執行更改）

拆分大事務的話基本會提高并發量，降低死鎖幾率，減小slave延遲，是不是全部采用“小”事務就萬事ok啦？

萬事沒有絕對，對于insert 語句，我有200w行記錄，我執行200w次送出，這樣事務就足夠小啦；

這樣并發量很高，基本無死鎖，但master 和slave的IO 就快要受不了啦；

首先從SQL語句解析上，就需要解析200w次（暫不考慮使用prepare statement的情況）

其次如果insert字段中包含主鍵，那基本上是insert 一次，commit一次，就會産生一次IO，也就是會産生>=200w次IO；如果是非主鍵的話，innodb會利用其 insert buffer,change buffer等就合并IO，但這樣做的效率不會顯著太多，程式端在不斷的insert；可以考慮每次送出2000條，分多次送出；這樣就會降低IO使用率，slave可以平穩的過度；

什麼時候事務保證足夠的并發量，又要降低IO使用率呢，這杆秤還是需要DBA來實時的觀察，比如借助zabbix這樣優秀的監控工具，監控你的QPS，響應時間，IO使用率适當的調整！

有什麼疑問随時讨論！

本文轉自 位鵬飛 51CTO部落格，原文連結：http://blog.51cto.com/weipengfei/1314697，如需轉載請自行聯系原作者