什么是enum？enum是電話號碼映射(e.164 number uri mapping)的縮寫。這個縮寫的后面隱藏著一個偉大的創意:即通過最好和最廉價的路由途徑，可以在世界任何地點使用同一個電話號碼。您可以象注冊域名一樣注冊enum號碼。
在開發項目時通常會遇到一些狀態字段，例如訂單的狀態有 待支付、已支付、已關閉、已退款 等，我以前做的項目都是把這些狀態用數字存在數據庫中，然后在 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 類型的字段）都會報錯
[DoctrineDBALDBALException] Unknown?database?type?enum?requested,?DoctrineDBALPlatformsMySQL57Platform?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',?'success',?'closed']?as?$status)?{ ??$data[$status]?=?[]; ??for?($i?=?0;?$i??$status]; ??} } ?? for?($i?=?0;?$i?<p>測試過程#</p><p>測試1#</p><p>在 enum 值列表最后添加一個值 refunded</p><pre class="brush:php;toolbar:false">ALTER?TABLE?`enum_tests`?CHANGE?`status`?`status`?ENUM('pending','success','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','success','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','success','refunded',?'closed')?CHARACTER?SET?utf8mb4?COLLATE?utf8mb4_unicode_ci?NOT?NULL;
? ?
輸出：
Query?OK,?1000000?rows?affected?(6.00?sec) Records:?1000000?Duplicates:?0?Warnings:?0
? ?
結論：在原 enum 值列表中間新增值需要全表掃描并更新，成本較高。
測試 4：#
刪除值列表中間的值
ALTER?TABLE?`enum_tests`?CHANGE?`status`?`status`?ENUM('pending','success','closed')?CHARACTER?SET?utf8mb4?COLLATE?utf8mb4_unicode_ci?NOT?NULL;
? ?
輸出：
Query?OK,?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 類型作為存儲狀態的數據類型。
相關推薦：
