慎用 MySQL ENUM 型別：PHP 弱型別陷阱與最佳替代方案

ENUM 型別的爭議

MySQL ENUM 型別允許在建表時預定義一組允許值，看似能提供資料完整性約束。然而在 PHP 等弱型別語言環境下，極易引發「數值與字串混淆」的嚴重 Bug，資深開發者普遍建議改用 TINYINT + 應用層常數/字典表。

核心問題：PHP 弱型別導致的靜默錯誤

CREATE TABLE `enum2tinyint` (
  `switchs` ENUM('none','success','fail','delete','skip','1') DEFAULT NULL,
  `switch` TINYINT(1) NOT NULL,
  KEY `switchs` (`switchs`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

正確插入（帶引號）

INSERT INTO `enum2tinyint` (`switchs`, `switch`) VALUES ('1', '1');
-- switchs = '1'（第 6 個枚舉值），switch = 1

錯誤插入（無引號，PHP 常見寫法）

INSERT INTO `enum2tinyint` (`switchs`, `switch`) VALUES (1, '1');
-- switchs = 'none'（第 1 個枚舉值）！

INSERT INTO `enum2tinyint` (`switchs`, `switch`) VALUES (2, '1');
-- switchs = 'success'（第 2 個枚舉值）！

根因：MySQL 內部將 ENUM 映射為整數索引（1-based）。PHP 變數 $val = 1 直接拼入 SQL 時未加引號，MySQL 視為數值索引而非字串值。這類 Bug 極難排查，因語法正確、不報錯、資料卻錯誤。

ENUM 儲存原理與空間分析

• ENUM 值在磁碟上以整數索引儲存（1 或 2 位元組，視枚舉數量）。
• ENUM('a','b','c') → 內部映射：1→'a', 2→'b', 3→'c'。
• 網路傳輸時仍傳回字串值，但應用層若直接用整數比較會出錯。

TINYINT 對比

TINYINT 位寬說明

TINYINT(1)、TINYINT(4) 儲存範圍完全相同，括號內數字僅為顯示寬度（配合 ZEROFILL），不影響儲存上限。建議統一使用 TINYINT UNSIGNED（0~255）。

最佳實踐建議

1. 新專案禁用 ENUM，改用 TINYINT UNSIGNED。
2. 在應用層定義常數類別/枚舉類，例如 PHP：

class OrderStatus {
    const PENDING = 0;
    const PAID    = 1;
    const SHIPPED = 2;
    const DONE    = 3;
    const CANCEL  = 4;

    public static function labels() {
        return [
            self::PENDING  => '待付款',
            self::PAID     => '已付款',
            self::SHIPPED  => '已發貨',
            self::DONE     => '已完成',
            self::CANCEL   => '已取消',
        ];
    }
}

3. 或建立字典表 dict_order_status(code, label, sort)，透過外鍵關聯，支援動態新增狀態無需改表結構。
4. 若歷史表已用 ENUM 且改動成本極高，可暫時保留，但嚴格要求所有 SQL 參數綁定時強制加引號（PDO 預處理自動處理）。

結語

ENUM 看似方便，實則在弱型別語言環境下埋下巨大隱患。採用 TINYINT + 應用層語意映射，不僅消除 Bug，還獲得更靈活的擴充性與更清晰的程式碼語意。這是現代 MySQL 開發的共識最佳實踐。