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

距離新年促銷只剩 15 分鐘，MyISAM 表鎖導致的雪崩效應正在蔓延。

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

機柜上的 IBM 服務器發出悲鳴，show status顯示著觸目驚心的數據：

| Table_locks_immediate | 184392 |
| Table_locks_waited    | 128647 |  # 鎖等待次數超12萬

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

行級鎖

死鎖監控屏上的量子糾纏

切換引擎后，林淵在innodb_lock_monitor輸出中發現了詭異現象：

圖片

"這是典型的交叉死鎖！"林淵調出鎖結構解析圖：

圖片

鎖機制降維打擊

對比 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正常執行

預寫日志：時空裂縫中的存檔點

跨年夜的數據火種

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

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

圖片

"看這個 LSN 序列！"他調出日志解析：

圖片

Change Buffer

訂單洪峰下的 IO 風暴

促銷期間監控顯示異常：

圖片

"這是把 IOPS 壓力轉嫁給 CPU！"林淵在黑板推導：

圖片

現場測試數據震撼團隊：

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

技術哲學

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

林淵畫出硬件發展曲線圖：

圖片

"我們現在用空間換時間，未來..."他頓了頓，"這些設計會讓 InnoDB 統治數據庫世界。"