1

我正在使用 mysql 数据库。我的网站分为不同的元素（项目 12 的 PRJ_12、任务 14 的 TSK_14、文档 18 的 DOC_18 等）。我们目前将这些元素的引用存储在我们的数据库中作为 VARCHAR。关系列已编入索引，因此选择起来更快。

我们正在考虑将这些列分为 2 列（在列“element_type”上使用 PRJ，在一个“element_id”上使用 12）。我们正在考虑这个解决方案，因为我们做了很多包含 LIKE ...% 的请求（例如检索一个用户的所有任务，无论任务的 id 是什么）。但是，将这些列分成 2 列会增加索引列的数量。

所以，我有两个问题：

  1. 索引列中的LIKE ...%请求是否真的比简单的 where 查询慢（没有类似）。我知道如果该列未编入索引，则不建议进行where ... LIKE %请求，但我真的不知道索引是如何工作的）。
  2. 我们将参考列一分为二的事实将使索引表的数量增加一倍。那是问题吗？

谢谢，

4

2 回答 2

1

1）点赞总是比完整比较（使用 = ）更昂贵，但这一切都归结为字段数据类型和记录数（除非我们谈论的是一个巨大的表，否则你不应该有问题）

2）多列索引不是问题，是的，它使索引更大，但那又怎样？数据类型和总行数很重要，但这就是索引的用途。

所以去吧

于 2013-02-07T16:32:05.020 回答
0

这涉及到许多因素，但总的来说，在只有一个索引的表上再添加一个索引不太可能是一个大问题。有些事情要考虑。

  • 如果表大多是只读的，那么它几乎肯定不是问题。如果更新很少，则不需要经常修改索引，这意味着额外的成本很少（除了额外的磁盘空间）。
  • 如果对现有记录的更新不会更改这些键值中的任何一个，则不需要修改索引，因此也不会产生额外的运行时成本。
  • DELETES 和 INSERTS 将需要更新两个索引。因此，如果这是大多数操作（并且远远超过读取），那么额外的索引可能会导致可测量的性能下降（但从人类的角度来看，它可能不会很多并且不明显）。
  • 您描述用法的like 运算符应完全优化。换句话说，该子句的执行应该与在这两种情况下都存在索引的情况WHERE combinedfield LIKE 'PRJ%'基本相同。WHERE element_type = 'PRJ'更昂贵的情况是如果您在开头使用通配符（例如，LIKE '%abc%'）。您可以将 LIKE 搜索视为等同于在字典中查找单词。搜索“overf%”与搜索“overflow”基本相同。您可以在字典中进行“手动”二进制搜索，并快速找到以“overf”开头的第一个单词。搜索“%low”的成本要高得多。您必须扫描整个字典才能找到所有以“low”结尾的单词。
  • 从长远来看，拥有两个单独的字段来表示两个单独的值几乎总是更好，因为您可以构建更有效的查询，轻松执行连接等。

因此，根据给定的信息，我建议将其拆分为两个字段并索引这两个字段。

于 2013-02-07T17:50:06.643 回答