2003 年 12 月 31 日 23:45，北京中關(guān)村某電商公司機房。 林淵盯著監(jiān)控屏上瘋狂跳動的Table_locks_waited計數(shù)器，手指在鍵盤上懸停。

距離新年促銷只剩 15 分鐘，MyISAM 表鎖導(dǎo)致的雪崩效應(yīng)正在蔓延。

"小林！商品庫存表又被鎖死了！" 運維經(jīng)理老周扯著嘶啞的嗓子，"每秒 300 次更新請求，MyISAM 根本扛不住！"

機柜上的 IBM 服務(wù)器發(fā)出悲鳴，show status顯示著觸目驚心的數(shù)據(jù)：

| Table_locks_immediate | 184392 |
| Table_locks_waited    | 128647 |  # 鎖等待次數(shù)超12萬

林淵深吸一口氣："立即切換 InnoDB 引擎，這是最后的生路！"

行級鎖

死鎖監(jiān)控屏上的量子糾纏

切換引擎后，林淵在innodb_lock_monitor輸出中發(fā)現(xiàn)了詭異現(xiàn)象：

圖片

"這是典型的交叉死鎖！"林淵調(diào)出鎖結(jié)構(gòu)解析圖：

圖片

鎖機制降維打擊

對比 MyISAM 的表級鎖：

圖片

林淵在終端演示：

-- 會話A
BEGIN;
UPDATE stock SET count=count-1 WHERE sku_id=100;

-- 會話B
UPDATE stock SET count=count-1 WHERE sku_id=101;  # MyISAM下會阻塞，InnoDB正常執(zhí)行

預(yù)寫日志：時空裂縫中的存檔點

跨年夜的數(shù)據(jù)火種

零點鐘聲響起時，機房突然斷電。

重啟后老周面色慘白："庫存數(shù)據(jù)回滾了！" 林淵卻從容啟動恢復(fù)流程：

圖片

"看這個 LSN 序列！"他調(diào)出日志解析：

圖片

Change Buffer

訂單洪峰下的 IO 風(fēng)暴

促銷期間監(jiān)控顯示異常：

圖片

"這是把 IOPS 壓力轉(zhuǎn)嫁給 CPU！"林淵在黑板推導(dǎo)：

圖片

現(xiàn)場測試數(shù)據(jù)震撼團隊：

# 批量插入100萬條非唯一索引數(shù)據(jù)
MyISAM: 時間=62s, 磁盤寫入=1.2GB
InnoDB: 時間=14s, 磁盤寫入=230MB

技術(shù)哲學(xué)

"但這需要更強的 CPU 和內(nèi)存！"CTO 指著飆升的 CPU 曲線。

林淵畫出硬件發(fā)展曲線圖：

圖片

"我們現(xiàn)在用空間換時間，未來..."他頓了頓，"這些設(shè)計會讓 InnoDB 統(tǒng)治數(shù)據(jù)庫世界。"