我有一个至少具有6个联接的SQL查询。该查询需要10分钟或更长时间才能执行。
现在，我正在使用狮身人面像，我只是从该SQL查询中设置了一个源。
但是我在重新索引方面有问题。
联接之一是对字典表的联接，该表实际上经常更新。
每次字典更新后，我都必须重新索引源。
但是我不想更新整个索引。
例如:
这是SQL查询:
SELECT m.col1, m.col2. m.col3, d.col1 FROM MainTable m JOIN SupportTable t1 JOIN SupportTable t2 JOIN SupportTable t3 JOIN DictionaryTable d
当有人更新DictionaryTable时，我只想更新依赖于更新行的那部分索引。
我的目标是服装的实时界面。
数据库的大小非常大。
如何使分析查询更快？
我应该使用搜索引擎并建立重新索引机制，还是应该使用更合适的技术？
最佳答案
听起来像SPhinx实时索引可能更合适。
http://sphinxsearch.com/docs/current.html#rt-indexes
您可以只发送某些文档的更新，而不必重建整个索引以更新一些文档。
但是您只能更新文档上的所有字段。不仅可以更新许多文档上的d.col1，还需要提供所有受影响文档的所有字段(和属性)的所有数据。
但是，您可以更新文档的选择属性，而无需触摸字段和/或其他属性。
另一个想法是代替一个大索引，将索引分解为几位-即“分片”索引。您甚至可以使用分布式索引来轻松一次查询所有分片。 (即，对于仅显示一个索引的应用程序，您无需手动搜索单独的分片)
http://sphinxsearch.com/files/tutorials/sphinx_config_tips_and_tricks.pdf
...这样可以滚动更新分片。即，而不是一个“10分钟”查询，它分为4个分片，并且更新量小得多。
(远程查询甚至可以用于分解成许多较小的查询，而不是一个2.5分钟的查询)
http://sphinxsearch.com/docs/current.html#ranged-queries
关于elasticsearch - 如何在像Elastic这样的搜索引擎中使用许多联接来管理SQL查询？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/52533115/