在开发项目时通常会遇到一些状态字段,例如订单的状态有 待支付、已支付、已关闭、已退款 等,我以前做的项目都是把这些状态用数字存在数据库中,然后在 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', 'success', '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', 'success', 'closed']); EnumTest::insert($data[$status]); }
测试过程#
测试1#
在 enum 值列表最后添加一个值 refunded
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 类型作为存储状态的数据类型。
MySQL,enum
稳了!魔兽国服回归的3条重磅消息!官宣时间再确认!
昨天有一位朋友在大神群里分享,自己亚服账号被封号之后居然弹出了国服的封号信息对话框。
这里面让他访问的是一个国服的战网网址,com.cn和后面的zh都非常明白地表明这就是国服战网。
而他在复制这个网址并且进行登录之后,确实是网易的网址,也就是我们熟悉的停服之后国服发布的暴雪游戏产品运营到期开放退款的说明。这是一件比较奇怪的事情,因为以前都没有出现这样的情况,现在突然提示跳转到国服战网的网址,是不是说明了简体中文客户端已经开始进行更新了呢?
更新日志
- 雨林唱片《赏》新曲+精选集SACD版[ISO][2.3G]
- 罗大佑与OK男女合唱团.1995-再会吧!素兰【音乐工厂】【WAV+CUE】
- 草蜢.1993-宝贝对不起(国)【宝丽金】【WAV+CUE】
- 杨培安.2009-抒·情(EP)【擎天娱乐】【WAV+CUE】
- 周慧敏《EndlessDream》[WAV+CUE]
- 彭芳《纯色角3》2007[WAV+CUE]
- 江志丰2008-今生为你[豪记][WAV+CUE]
- 罗大佑1994《恋曲2000》音乐工厂[WAV+CUE][1G]
- 群星《一首歌一个故事》赵英俊某些作品重唱企划[FLAC分轨][1G]
- 群星《网易云英文歌曲播放量TOP100》[MP3][1G]
- 方大同.2024-梦想家TheDreamer【赋音乐】【FLAC分轨】
- 李慧珍.2007-爱死了【华谊兄弟】【WAV+CUE】
- 王大文.2019-国际太空站【环球】【FLAC分轨】
- 群星《2022超好听的十倍音质网络歌曲(163)》U盘音乐[WAV分轨][1.1G]
- 童丽《啼笑姻缘》头版限量编号24K金碟[低速原抓WAV+CUE][1.1G]