1

在一个项目中工作，其中架构是这样的：

id , key, value

和列是 varchar，表key是.valueInnoDB

用户可以根据键值对进行搜索……在 MySQL 中查询的最佳方式是什么？我能想到的选项是：

  • 对于每个key => value表单，查询并执行inner join以id匹配所有条件。

  • 或者在后台， 使用on和单个查询填充一个MyISAM表。如果网站很受欢迎并且表有十万行，那么稍后将有这样的好处，我可以轻松地将代码移植到 Lucene，但现在是 MySQL。id, infoFull Text indexinfolike '%key:value%key2:value2%'

4

2 回答 2

2

您正在谈论的模式称为关系除法。

如果您有正确的索引，选项 #1（自连接）是一个更快的解决方案。

我在演示 SQL Query Patterns, Optimized中比较了几个解决方案与关系划分的性能。自联接解决方案即使针对具有数百万行的表也能在 0.005 秒内工作。

带有全文的选项＃2 无论如何都是不正确的，因为您不会使用LIKE全文搜索。你会用MATCH(info) AGAINST('...' IN BOOLEAN MODE). 我不确定您是否可以在key:value格式中使用模式。MySQL FTS 更喜欢匹配单词。

于 2013-04-09T17:32:10.270 回答
0

@比尔卡尔文

如果您要针对 1 个条件执行此操作，则使用这种类似 EAV 的模式会非常快，但如果您针对许多情况执行此操作（尤其是使用混合的 AND 和 OR），它可能会分崩离析。您可以期望的最好的结果是某种超快速的索引合并，这是难以捉摸的。如果您做任何花哨的事情，您将在大多数 DBMS 中获得一个临时表。不过，我想我记得读过你不是 EAV 的粉丝，也许我误解了你。

我记得，DBMS 也可以自由地进行多次扫描，然后使用一次性位图索引来处理。但是全文索引使文档列表保持排序，并使用 FTS 规划器在所有标准上进行低成本合并，该规划器从战略上从稀有关键字开始。这就是他们整天执行“word1 & word2”所做的一切。它们针对这类事情进行了优化。

因此，如果您有很多简单的事实，我认为 FTS 索引是一种不错的方法。我错过了什么吗？您只需将事实更改为可索引的内容，如 COLORID_3，然后搜索“COLORID_3 & SOMETHINGELSEID_5”。

如果查询不涉及合并或排序，我怀疑它几乎是清洗。这里除了我们 BTREEs 什么都没有......

于 2013-04-16T06:00:46.120 回答