MySQL 單表突破 4GB 限制實戰（上）：問題診斷與檔案系統驗證

論壇出現 The table is full 錯誤，實際上是 MyISAM 表單檔案觸及 4GB 上限（32 位檔案指標限制）。本文記錄真實案例：雙 Athlon + SCSI 72G + 2G RAM 環境，帖子表達 4.29GB 逼近極限，完整展示從作業系統、檔案系統到 MySQL 參數的排查與突破過程（上）。

錯誤觸發的兩大場景

1. MAX_ROWS 設定過小：嘗試寫入超過上限的筆數。
2. 單表檔案達 4GB 物理上限（本文重點）：MyISAM .MYD 檔案在 32 位系統上受限於 4GB（2^32 bytes）。

案例環境基線

# uname -a
Linux zichen.com 2.4.20-8smp #1 SMP Thu Mar 13 16:43:01 EST 2003 i686 athlon i386 GNU/Linux
# cat /etc/*release*
Red Hat Linux release 9 (Shrike)

確認為 Red Hat 9，Kernel 2.4.20 SMP（支援大檔案）。

檔案系統驗證：EXT3 支援 2TB 單檔

# parted /dev/sda print
Disk geometry: 0.000-70149.507 MB
Minor  Start      End        Type      Filesystem  Flags
1      0.031      101.975    primary   ext3        boot
2      101.975    10103.378  primary   linux-swap

• EXT3 繼承 EXT2 並加入日誌，單檔上限從 2GB 提升至 2TB，非 OS 層面瓶頸。
• Kernel 2.4.x 需啟用 CONFIG_LARGE_FILE（Red Hat 9 預設開啟）。

MySQL 端確認：表狀態與參數

SHOW TABLE STATUS FROM forum LIKE 'posts'\G
-- 關鍵欄位：
-- Data_length: 4294963640 (~4.0 GB)
-- Max_data_length: 4294967295 (4GB - 1，MyISAM 32 位上限)
-- Create_options: max_rows=... avg_row_length=...

Max_data_length 顯示 4294967295，確認已觸及 MyISAM 內部 32 位檔案指標上限。

突破方案預覽（下篇將詳述）

1. ALTER TABLE ... MAX_ROWS=... AVG_ROW_LENGTH=...：調大內部指標空間，讓 MyISAM 使用 64 位指標（需 MySQL 3.23+）。
2. 轉換為 InnoDB：InnoDB 表空間無 4GB 單檔限制，支援 64 位檔案指標，且具備交易與行鎖優勢。
3. 分表/分區：按時間或 ID 範圍拆分，根治單表膨脹。

操作前必備

• 完整備份（mysqldump 或檔案級複製）。
• 停機視窗：ALTER TABLE 會重建表，大表耗時久並鎖表。
• 磁碟空間預留：重建過程需雙倍空間。

下篇將實測 ALTER TABLE ... MAX_ROWS=1000000000 AVG_ROW_LENGTH=100 與 ALTER TABLE ... ENGINE=InnoDB 兩種方案的執行耗時、檔案大小變化與效能對比。