在開發專案時通常會遇到一些狀態欄位，例如訂單的狀態有 待支付、已支付、已關閉、已退款 等，我以前做的專案都是把這些狀態用數字存在資料庫中，然後在 php 程式碼中用常量來維護一份對映表，例如：

const STATUS_PENDING = 0;
const STATUS_PAID = 1;
const STATUS_CLOSED = 2;
const STATUS_REFUNDED = 3;

但是在實際使用過程中發現並不是那麼好用，由於各種原因（追查 bug、臨時的統計需求等）我們常常需要登入到 mysql 伺服器裡手動執行一些 sql 查詢，由於許多表都有狀態欄位，寫 sql 時必須對照的 php 程式碼裡的對映關係來寫，一不小心還有可能將不同表的狀態數字弄混導致大問題。

於是我在新專案中準備使用 mysql 的 enum 型別來儲存各種狀態，在使用過程中發現如果在 Laravel 的 migration 檔案中對使用了 enum 型別的表做變更（即使是變更非 enum 型別的欄位）都會報錯

[Doctrine\DBAL\DBALException]
Unknown database type enum requested,Doctrine\DBAL\Platforms\MySQL57Platform may not support it.

搜尋了一下，發現是 doctrine 不支援 mysql 的 enum，該文中列舉了 enum 的 3 個缺點：

新增 enum 值的時候需要重建整個表，當資料量大的時候可能需要耗費數小時。

enum 值的排序規則是按建立表結構時指定的順序，而非字面值的大小。

依賴 mysql 對 enum 值的校驗並不是非常必要，在預設配置下插入非法值最終會變成空值。

根據新專案的實際情況，不太可能出現需要對狀態欄位做排序的需求，即使有我們可以在設計表結構的時候就定好順序，因此缺點 2 可以忽略；而缺點 3 則可以通過程式碼規範、插入/更新前校驗等方式來規避；至於缺點 1，我們需要做一些測試。

測試準備#

首先建立一個表：

CREATE TABLE `enum_tests` (
 `id` int(10) unsigned NOT NULL AUTO_INCREMENT,`status` enum('pending','success','closed') COLLATE utf8mb4_unicode_ci NOT NULL,PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

然後插入 100W 條資料：

$count = 1000000;
$bulk = 1000;
$data = [];
foreach (['pending','closed'] as $status) {
  $data[$status] = [];
  for ($i = 0; $i < $bulk; $i++) {
    $data[$status][] = ['status' => $status];
  }
}

for ($i = 0; $i < $count; $i += $bulk) {
  $status = array_random(['pending','closed']);
  EnumTest::insert($data[$status]);
}

測試過程#

測試1#

在 enum 值列表最後新增一個值 refunded

ALTER TABLE `enum_tests` CHANGE `status` `status` ENUM('pending','closed','refunded') CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NOT NULL;

輸出：

Query OK,0 rows affected (0.04 sec)
Records: 0 Duplicates: 0 Warnings: 0

結論：在末尾追加 enum 值時幾乎沒有成本。

測試 2：#

刪除剛剛新增的值 refunded

ALTER TABLE `enum_tests` CHANGE `status` `status` ENUM('pending','closed') CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NOT NULL;

輸出：

Query OK,1000000 rows affected (5.93 sec)
Records: 1000000 Duplicates: 0 Warnings: 0

結論：刪除一個沒有用過的 enum 值仍需全表掃描，成本較高，但還在可接受範圍內。

測試 3：#

將 refunded 插入到值列表中間而非末尾

ALTER TABLE `enum_tests` CHANGE `status` `status` ENUM('pending','refunded',1000000 rows affected (6.00 sec)
Records: 1000000 Duplicates: 0 Warnings: 0

結論：在原 enum 值列表中間新增值需要全表掃描並更新，成本較高。

測試 4：#

刪除值列表中間的值

ALTER TABLE `enum_tests` CHANGE `status` `status` ENUM('pending',1000000 rows affected (4.23 sec)
Records: 1000000 Duplicates: 0 Warnings: 0

結論：需全表掃描，成本較高。

測試 5：#

給 status 欄位新增索引後再執行上述測試

ALTER TABLE `enum_tests` ADD INDEX(`status`);

發現測試 2-4 的耗時反而有所增加，應該是同時需要更新索引導致的。

結語：#

對於我的新專案來說只會出現新增 enum 值的情況，即使將來有個別狀態廢棄不用也不需要去調整 enum 的值列表，因此決定在專案中引入 enum 型別作為儲存狀態的資料型別。