“where”或“like”子句更适合使用索引答案

【问题标题】："where" or "like" clause is better for using index“where”或“like”子句更适合使用索引
【发布时间】：2015-10-21 23:18:16
【问题描述】：

我有一个表，其中包含 SET 类型的列，例如 SET('abc','def','ghi') 存储像 "abc,ghi" 这样的数据，我索引这些列。所以当我想找到"def" 或"ghi" 我必须使用LIKE "%def%" 但我读到"%" 如果你使用它作为第一个字符mysql 不使用索引进行搜索。我该怎么办？我应该将类型更改为枚举并将每个值存储在具有如下 ID 的单独行中：

+---------+
| column  |
+---------+
| abc     |
| abc,ghi |
| abc,def |
| ghi,def |
+---------+

改为：

+----+--------+
| ID | column |
+----+--------+
| 1  | abc    |
| 2  | abc    |
| 2  | ghi    |
| 3  | abc    |
| 3  | def    |
| 4  | ghi    |
| 4  | def    |
+-------------+

或者有什么东西可以操纵索引来分别存储每个单词？

【问题讨论】：

So when I want to find "def" or "ghi" I have to use LIKE "%def%" 不要那样做。使用子表来表示集合的元素。 ` 我读到“%”，如果你使用它作为第一个字符 mysql 不使用索引进行搜索`这就是原因。
我不明白你能解释一下吗？ @Eric J.

标签： mysql indexing where-clause

【解决方案1】：

在集合中查找项目的正确函数是FIND_IN_SET。集合存储为位图，而不是字符串，FIND_IN_SET 不必像LIKE 那样在匹配之前将其转换为字符串。但它仍然无法使用索引。

您的第二个架构是规范化数据的正确方法。您可以在column 列上放置索引，查找值的查询将是有效的。在本专栏中使用ENUM 还是VARCHAR 是数据库社区内激烈争论的主题。

【讨论】：

但它占用大量磁盘空间？你不觉得吗？我应该在未来考虑还是不考虑？
是的，这是一个折衷方案——它使用更多空间，但会提高速度并减少 CPU 负载。
在大多数情况下，磁盘空间比在列中 %match% 数据的 CPU 和 IO 成本要便宜得多。
索引是 B 树。您无法优化 B 树中的位图。