工作的一个项目，其中的模式是这样的：MySQL的搜索FTS VS多个查询
id , key, value
的key和value列varchar和表是InnoDB。
用户可以根据键值对进行搜索......在MySQL中查询的最佳方式是什么？我能想到的选项是：
对于每个key => value形成一个查询和执行inner join得到id匹配所有指标分析。
或后台，填充MyISAM表id, info与Full Text index上info和使用like '%key:value%key2:value2%'单个查询。如果网站很受欢迎，并且表格有十万行，那么这样做的好处将在后面提到，我可以轻松地将代码移植到Lucene，但现在是MySQL。
您所说的模式被称为关系分区。
如果你有正确的索引，选项＃1（自联接）是一个更快的解决方案。
我比较了几种解决方案在我的演示文稿中的关系部门的性能 SQL Query Patterns, Optimized。即使对数百万行的表格，自联接解决方案也能在0.005秒内工作。
无论如何，全文选项＃2是不正确的，因为您不会使用LIKE进行全文搜索。你会使用MATCH(info) AGAINST('...' IN BOOLEAN MODE)。无论如何，我不确定你可以使用key:value格式的模式。 MySQL FTS更喜欢匹配单词。
@Bill Karwin
如果你打算为1种条件下做到这一点，它会随着这EAV样的架构超快速的，但如果你对很多（特别是混合AND和OR做）它可能会分崩离析。你可以期望的最好的方式就是进行某种超快速索引合并，这是难以捉摸的。如果你想做任何事情，你会在大多数DBMS中得到一个临时表。我想我记得读过你并不是EAV的粉丝，但也许我误解了你。
我记得，一个DBMS也可以自由地做多个扫描，然后用一次性位图索引处理这个。但是全文索引可以保持文档列表的排序，并通过FTS规划器在所有条件下进行低成本合并，从而以较少的关键字进行战略性开始。这就是他们整天执行“word1 & word2”所做的一切。他们为这种事情进行了优化。
所以，如果你有很多简单的事实，FTS指数是一个体面的做法，我认为。我错过了什么吗？您只需将事实更改为COLORID_3等可索引的内容，然后搜索“COLORID_3 & SOMETHINGELSEID_5”。
如果查询不涉及合并或排序，我怀疑它几乎就像洗脸一样。这里没有，但我们BTREEs ...
是的，这是EAV为何效率低下的一个很好的例子。你必须做关系分工来模仿传统的表格设计可以用AND来完成什么。 – 2013-04-17 00:37:48
我认为提问者应该澄清。如果做AND，FTS或元组更好。由于这个原因，MS-SQL实现了稀疏列。稀疏元组比EAV好得多。它支持热添加，NULL为1位。还有另一个问题。关系划分不能表示相关性。元组做的很好:)但是使用FTS将会是您找到的索引合并类型查找的最快实现。抓取列表，根据需要对它们进行排序，做一个排序的交集。即使与FTS相似，EAV查询几乎也不会这样做。那么为什么关系分工？ FTS可能会更好。 – 2013-04-17 23:50:53
尽可能地，我尝试推荐能够与OP当前数据库一起工作的解决方案，而不需要进行大规模的重构或切换到其他技术。人们通常想知道他们今天如何解决他们的问题，而不是他们如何花6个月时间迁移到另一个平台来解决问题。 :-) – 2013-04-17 23:55:28
我不认为后者会更快，因为我们使用像。 – srinath 2013-04-09 17:27:12