MySQL：枚举与带索引的 Varchar

Question

假设，我需要创建一个表，其中一列将具有来自这个有限且永不更改的集合的值： 'all'、'local'、'qa'、'staging' 和 'production'。

在这种情况下使用enum 数据类型看起来是一个合适的解决方案，但是在阅读了this article 和互联网上的其他一些帖子之后，我觉得不鼓励使用它。所以，如果我不想要创建一个查找表并且保持evn和name的组合唯一也是一个要求，那么我最好的选择是什么具有 ENUM 类型的列和具有 VARCHAR 类型但在其上创建了索引的列。

同时考虑到此表中的插入很少见，我们希望此特定查询执行得更快：

SELECT `enabled` FROM `features`
WHERE `name` = 'some_featuere'
AND `env` IN('all', 'qa')
ORDER BY `enabled` ASC limit 1;

其中哪一个是更好的设计，为什么？

CREATE TABLE `features` (
  `id` INTEGER  NOT NULL AUTO_INCREMENT,
  `name` VARCHAR (50) NOT NULL,
  `env` ENUM('all', 'local', 'qa', 'staging', 'production') NOT NULL,
  `enabled` TINYINT(1) DEFAULT 0,
  `created_at` DATETIME,
  `updated_at` DATETIME,

  PRIMARY KEY (`id`),
  UNIQUE KEY `idx_unq_features_name_env` (`name`,`env`)
);

或

CREATE TABLE `features` (
  `id` INTEGER  NOT NULL AUTO_INCREMENT,
  `name` VARCHAR (50) NOT NULL,
  `env` VARCHAR(10) NOT NULL,
  `enabled` TINYINT(1) DEFAULT 0,
  `created_at` DATETIME,
  `updated_at` DATETIME,

  PRIMARY KEY (`id`),
  INDEX `idx_features_env` (`env`),
  UNIQUE KEY `idx_unq_features_name_env` (`name`,`env`)
);

Answer 1

对您的问题的简短回答是“两者都不是”，因为您的查询在这两种情况下都会使用名称/env 上的索引。但是，如果我必须解决一个问题，我会选择 VARCHAR 而不是 ENUM，因为它是两个弊端中较小的一个，但我认为您的方法可能存在其他一些问题。

首先，VARCHAR 选项只会重复该文章中提到的 ENUM 问题（即添加属性或相关数据），而可能失去您可能从 ENUM 获得的唯一优势，即数据完整性。您可以通过查找获得数据完整性，而无需 ENUM 的邪恶。

其次，您可能关注的是查询不存在的性能问题。它多久运行一次？它有多慢？就目前而言，您在NAME/ENV 上有一个索引，我想不出加快查询速度的唯一方法是包含ENABLED 的覆盖索引，但我怀疑它是性能杀手，因为它是，我怀疑你会看到加入查找表的差别很小。

第三，“ALL”作为一个选项几乎没有意义，除非一项功能一次只能部署在一个环境中或同时部署在所有环境中。如果这不成立，那么每当您想应用“ALL”选项时，您就必须删除与功能名称相关的所有其他记录。 “ALL”还可以防止在不同环境中选择性地启用/禁用功能或单独记录创建/更新事件。这引入了不需要存在的数据管理问题。

第四，ID、NAME、CREATED_AT、UPDATED_AT 列都是与功能直接相关的属性。 ENV 和 ENABLED 列与该功能的部署位置和方式相关。乍一看，这表明将这些数据存储在一个完全独立的表中（可能使用CREATED_AT 和UPDATED_AT 来指示它们首次部署和最后更新的时间）。我个人会使用 Feature、Environment 和 Feature_Environment 作为单独的表，外键从 Feature_Environment 到另外两个。

Answer 2

亲 ENUM 和反 ENUM 派别之间正在进行一场“宗教”战争。您已阅读其中一篇“反”文章。但是那篇文章中的许多“邪恶”可能不适用于您的情况。

如果当前的 PK id 被删除并将其替换为

，可以加快您的查询速度

PRIMARY KEY(name, env)

之后，就不需要二级索引了。

您需要在辅助键中查找，然后进入 PK 以获取第三列。之后，排序并交付一行。

更改 PK 可避免额外查找。而且这种变化不应该有“不利因素”。

如果表中有数百万行，并且每个env 要求的值可能有数千个候选者，那么这会更快，因为它不会收集“数千”行，对它们进行排序，只送一份。相反，它得到两行并从中挑选：

    (   SELECT  `enabled`
            FROM  `features`
            WHERE  `name` = 'some_featuere'
              AND  `env` = 'all'
            ORDER BY  `enabled` ASC
            limit  1
    )
    UNION DISTINCT
    (  SELECT  `enabled`
            FROM  `features`
            WHERE  `name` = 'some_featuere'
              AND  `env` = 'qa'
            ORDER BY  `enabled` ASC
            limit  1 
    )
    ORDER BY  `enabled`
    LIMIT  1;

是的，ORDER BY 和 LIMIT 重复了。对于小型数据集，我不推荐 OR --> UNION，因为有很多步骤，每个步骤都有开销。

无论您使用 ENUM 还是其他方法，我的答案都适用。它确实假设 InnoDB。

Answer 3

这是一个不同的答案 - 使用 SET 数据类型。

以下是表格更改：

`env` SET('local', 'qa', 'staging', 'production') NOT NULL,
PRIMARY KEY (`name`)

没有辅助键，没有'all'，每个name只有一行。

但是，测试变得更加混乱。还是变简单了？？那是

AND `env` IN('all', 'qa')

-->

AND env = 'qa'

因为现在测试只针对一件事。凌乱的all 不见了。

如果一切都符合业务逻辑，那么表和查询就更简单、更快了。

如果我在业务逻辑上错了，请详细说明。可能有办法挽救这个答案（使用SET 而不是IN）。