MySQL 核心參數優化：table_cache 與 key_buffer_size 深度解析

前言：MySQL 效能調校的藝術

MySQL 伺服器效能調優猶如精雕細琢的藝術，其中 table_cache（表緩存）與 key_buffer_size（索引緩衝區）是影響資料庫響應速度的兩大核心參數。本文結合實戰經驗，深入剖析這兩個參數的運作機制、監控指標與調優策略，助您找到最適配的配置平衡點。

一、table_cache：表緩存的「黃金法則」

1. 運作原理

table_cache 定義了 MySQL 可同時打開的表緩存數量。當執行緒存取資料表時，若緩存中已存在該表，則直接讀取；若緩存有空間，則打開表並放入緩存；若緩存已滿，MySQL 會依規則釋放閒置表或臨時擴展緩存。良好的表緩存機制能顯著降低檔案開啟/關閉的系統開銷，提升 SQL 響應速度。

2. 關鍵監控指標：Open_tables 與 Opened_tables

判斷是否需擴大 table_cache 的核心依據為峰值時段的狀態值：

• Open_tables：當前打開的表數量。
• Opened_tables：歷史累計打開的表數量。

調優信號：若 Open_tables 接近 table_cache 設定值，且 Opened_tables 持續快速增長，表明緩存不足，頻繁觸發磁碟 I/O，需適度增大該參數。

3. 避開「越大越好」的誤區

預設值隨實體記憶體增長（2GB 以下 256~512，4GB 為 2048），但盲目調大易引發副作用：

• 死鎖風險上升：過大的緩存增加並發競爭，導致死鎖頻發，反拖慢整體效能。
• 檔案描述符耗盡：每個緩存表消耗一個檔案描述符。配置檔中明確警告：open_files_limit 需至少設為 4096（4GB 記憶體建議 8192）。

系統層面修正：勿僅用 ulimit -n 臨時調整（換終端即失效），應修改 /etc/sysctl.conf 並同步設定 open_files_limit 參數。

二、key_buffer_size：MyISAM 索引加速的核心引擎

1. 參數定位

key_buffer_size 專供 MyISAM 儲存引擎使用，決定索引區塊的記憶體緩衝大小，直接影響索引讀取速度。即便主力引擎為 InnoDB，內部臨時表仍為 MyISAM，故此參數不可忽視。

2. 科學評估公式：命中率與未命中率

透過 SHOW GLOBAL STATUS LIKE 'Key_read%' 獲取：

• Key_read_requests：索引讀取請求總數（記憶體+磁碟）。
• Key_reads：直接從磁碟讀取索引的次數（未命中）。

關鍵比率：Key_reads / Key_read_requests

• 優秀：≤ 0.01%（1:10,000）
• 良好：≤ 0.1%（1:1,000）
• 需擴容：> 0.1%
• 過度分配：< 0.001%（可適度縮減）

實測案例：某 64GB 記憶體伺服器，將 key_buffer_size 從 512MB 調至 2048MB，未命中率從 0.024% 進一步降低，效能明顯提升且無記憶體溢位。

3. 緩存使用率輔助判斷

檢視 Key_blocks_used 與 Key_blocks_unused：

使用率 = Key_blocks_used / (Key_blocks_used + Key_blocks_unused) * 100% ≈ 80% 為理想區間。若接近 100%，需擴容或檢視是否存在過度索引。

4. 設定紅線與最佳實踐

• 32 位系統上限 4GB，64 位理論支援更大，但受限於 OS 行程記憶體上限。
• 建議佔物理記憶體 25%~40%（MyISAM 為主時），預留足夠記憶體給 OS 檔案系統緩存（MyISAM 數據讀取依賴 OS cache）。
• 避免超過 50%，否則觸發系統分頁，效能劇降。
• 高階玩法：MySQL 5.0+ 支援多 key_buffer，可將熱點表索引綁定專屬緩存（CACHE INDEX ... IN key_buffer_name + LOAD INDEX INTO CACHE）。

三、總結：動態平衡，持續迭代

效能優化無標準答案，唯有「觀測 → 分析 → 調整 → 驗證」的閉環。table_cache 重在匹配並發連接與表關聯複雜度，key_buffer_size 核心在於索引命中率與記憶體分配比例。切記：參數服務於業務負載，而非追求極值。建議建立基準線監控，定期複盤，讓 MySQL 在穩健中釋放極致效能。