MySQL「The table is full」錯誤根因分析與五大解決方案

MySQL 報錯 The table is full 並非單一原因，而是多種儲存層限制的統稱。本文系統梳理五大觸發場景，提供診斷查詢與精準解決方案。

場景一：舊版本臨時表超限（MySQL < 3.23）

現象： 內部臨時表超過 tmp_table_size 位元組。
方案：

• 啟動參數：mysqld -O tmp_table_size=1073741824（1GB）
• Session 級：SET SESSION SQL_BIG_TABLES=1; 或啟動 --big-tables

現狀： MySQL 3.23+ 已自動將超限記憶體臨時表轉為磁碟 MyISAM 表，**此場景歷史性消失**。

場景二：InnoDB 表空間耗盡

現象： ibdata1 或獨立表空間 .ibd 達到上限。
診斷：

SHOW VARIABLES LIKE 'innodb_data_file_path';

方案：

• 擴充現有檔案：innodb_data_file_path=ibdata1:12M:autoextend:max:100G
• 新增檔案：停機 → 編輯 my.cnf 新增路徑 → 重啟。
• 啟用 innodb_file_per_table=1 採用獨立表空間，單表獨立管理。

場景三：作業系統檔案大小 2GB 限制（32位系統/舊檔案系統）

現象： MyISAM .MYD 或 .MYI 達 2GB 上限。
方案：

• 升級 64 位 OS + 大檔案支援檔案系統（ext4, xfs, NTFS）。
• 將大表拆分為多個小表（分區表/手動分表）。
• 轉用 InnoDB（支援大檔案、獨立表空間）。

場景四：MyISAM 內部指標不足（MAX_ROWS / AVG_ROW_LENGTH）

現象： 資料量未達 OS 檔案上限，但 MyISAM 內部行指標（預設 6 位元組，支援 65536TB）因建表時未指定 MAX_ROWS 導致預估不足。
診斷：

SHOW TABLE STATUS FROM `db` LIKE 'tbl_name'\G
-- 關注 Max_data_length
myisamchk -dv /path/to/table.MYI

方案：

ALTER TABLE `tbl_name` MAX_ROWS=1000000000 AVG_ROW_LENGTH=100;

• AVG_ROW_LENGTH 僅對含 BLOB/TEXT 表必要，幫助 MySQL 精準預估空間。
• 操作會重建表，**大表需規劃停機窗口**。

場景五：MEMORY 引擎達 max_heap_table_size

現象： Memory 表寫入失敗，錯誤訊息同樣為 The table is full。
方案：

• Session 級調大：SET SESSION max_heap_table_size = 1073741824;（重建表生效）
• 或建表時指定：CREATE TABLE ... MAX_ROWS=... ENGINE=MEMORY（受 max_heap_table_size 制約）。

統一診斷流程圖

The table is full
    │
    ├─ InnoDB 表？ → 檢查 innodb_data_file_path / 磁碟空間 → 擴充表空間
    │
    ├─ MyISAM 表？ → 檢查 OS 檔案大小限制 / Max_data_length
    │                ├─ 2GB 限制 → 升級 OS/FS 或分表/轉 InnoDB
    │                └─ 指標不足 → ALTER TABLE MAX_ROWS=... AVG_ROW_LENGTH=...
    │
    ├─ MEMORY 表？ → 調大 max_heap_table_size
    │
    └─ 臨時表？  → MySQL 3.23+ 已自動轉磁碟，無需處理

預防性最佳實踐

• 所有表建表時顯式指定 MAX_ROWS、AVG_ROW_LENGTH（預估峰值 × 2）。
• 採用 innodb_file_per_table=1，單表獨立表空間，便於管理與回收空間。
• 監控告警：data_free、table_rows、磁碟使用率、InnoDB 表空間使用率。
• 定期 OPTIMIZE TABLE（MyISAM）或 ALTER TABLE ... ENGINE=InnoDB（InnoDB）回收碎片空間。

「The table is full」本質是**儲存容量規劃缺失**。建立容量基線、設定告警閾值、預留擴充通道，才是徹底解決之道。