MySQL 鎖粒度詳解：表鎖與行級鎖的特性、優缺點與適用場景

概述

鎖是資料庫併發控制的核心機制。MySQL 採用插件式存儲引擎架構，不同引擎支援的鎖粒度不同。本文聚焦於最基礎的兩種粒度——表鎖與行級鎖，分析其機制、開銷、並發特性及適用場景。

一、表鎖

特性

• 粒度最大、開銷最小：鎖定整張表，加鎖/解鎖速度快，無死鎖風險。
• 並發度最低：寫鎖獨佔整表，阻塞所有讀寫；讀鎖共享，允許並發讀，但阻塞寫。

讀寫鎖優先級與隊列

• 寫鎖優先級高於讀鎖：寫鎖請求可插隊到讀鎖隊列前面；讀鎖請求不可插到寫鎖前面。
• READ LOCAL 讀鎖允許特定並發寫操作（如尾部插入 MyISAM）。

Server 層強制表鎖場景

即使存儲引擎支援行鎖，MySQL Server 層仍會對 ALTER TABLE、LOCK TABLES 等語句使用表鎖，忽略引擎鎖機制。

二、行級鎖

特性

• 粒度最細、開銷最大：僅鎖定操作涉及的行，最大化並發處理能力。
• 僅在存儲引擎層實現：InnoDB、XtraDB 等事務型引擎支援；MySQL Server 層不實現行鎖。
• 可能出現死鎖：需應用層或引擎層檢測處理。

InnoDB 行鎖模式

• 記錄鎖：鎖定單個索引記錄。
• 間隙鎖：鎖定索引記錄間的間隙，防止幻讀。
• 臨鍵鎖：記錄鎖 + 間隙鎖，鎖定範圍。

三、對比總結與選型指南

四、最佳實踐建議

1. 核心業務表必選 InnoDB：行級鎖 + 事務支撐高併發寫入。
2. 避免隱式表鎖升級：無索引或索引失效的 UPDATE/DELETE 會導致 InnoDB 退化為全表掃描鎖定所有行（實際上鎖定所有記錄+間隙）。
3. 合理設計索引：讓鎖定範圍精確到業務需要的行，減少 Gap Lock 範圍。
4. 監控鎖等待：關注 Innodb_row_lock_waits、Innodb_row_lock_time_avg 等狀態變量。