MySQL Open_tables 與 Opened_tables 監控指標詳解：合理配置 table_open_cache 的科學依據

Open_tables（當前緩存打開表數）與 Opened_tables（歷史累計打開表數）是評估 table_open_cache 是否合理的核心指標。本文給出指標含義、健康度判斷公式、實際案例分析與配置建議。

一、指標含義

二、獲取方式

SHOW GLOBAL STATUS LIKE 'Open%tables';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| Open_tables   | 919   |
| Opened_tables | 1951  |
+---------------+-------+

三、健康度判斷公式

# 1. 緩存命中率
Hit_Rate = Open_tables / Opened_tables * 100%
-- 例：919 / 1951 = 47.1%  ⚠️ 過低，緩存嚴重不足

# 2. 緩存利用率
Usage_Rate = Open_tables / table_open_cache * 100%
-- 需配合 SHOW VARIABLES LIKE 'table_open_cache';
-- 例：table_open_cache=2048 → 919/2048 = 44.9%  利用率尚可

四、合理配置標準

Open_tables / Opened_tables * 100% >= 85%   -- 命中率達標
Open_tables / table_open_cache * 100% <= 95%  -- 利用率未滿，有擴容空間

五、實際案例分析

案例：電商訂單庫，高峰期 2000 QPS

# 觀察數據
Open_tables = 1850
Opened_tables = 42000  (1小時增長)
table_open_cache = 2048

# 判斷
Hit_Rate = 1850/42000 = 4.4%  極低
Usage_Rate = 1850/2048 = 90.3%  接近滿載

# 根因
table_open_cache 遠小於熱表數量，大量表被頻繁踢出又重新打開。

# 調優
SET GLOBAL table_open_cache = 10000;  -- 即時生效
# 同步更新 my.cnf
# 觀察 1 小時後
Opened_tables 增長趨緩，Hit_Rate 升至 92%。

六、配置建議流程

1. 部署後運行 1-2 周，記錄高峰期 Open_tables 峰值 P。
2. 設 table_open_cache = P * 1.3（預留 30% 增長緩衝）。
3. 同步調大 open_files_limit = table_open_cache * 3，系統 ulimit -n 同步跟上。
4. 持續監控 Hit_Rate，保持 > 85%。

七、常見誤區

• 以為 Opened_tables 只增不減是 Bug：它是累計計數器，正常只增不減，關鍵看增長速率。
• 盲目設極大值（如 100 萬）：會佔用大量內存存儲表定義對象，擠佔 Buffer Pool，得不償失。
• 忽略分區表影響：每個分區佔用一個緩存槽位，100 張表 × 12 分區 = 1200 槽位，需乘以分區數估算。

科學監控 Open_tables/Opened_tables，按「峰值 × 1.3」配置 table_open_cache，是 MySQL 表緩存層穩定運行的黃金法則。