我需要进行查询,例如
SELECT
Url, COUNT(*) AS requests, AVG(TS) AS avg_timeSpent
FROM
myTable
WHERE
Url LIKE '%/myController/%'
GROUP BY
Url
尽可能快地跑。
选择和分组的列几乎总是相同的,区别在于选择和分组上的额外列(列tenantId
)
我应该创建哪种索引来帮助我运行这种情况?
编辑1:
如果我将我的基本查询更改为' / myController /%' (注意乞讨时没有%
)会更好吗?
答案 0 :(得分:1)
这是一个无法用索引加速的查询。 DBMS无法事先知道有多少记录符合条件。它可能是100%或0.001%。 DBMS无法猜测这一点。只有当一小部分行被选中时,才能通过索引进行访问。
此外,这样的索引如何构建和有用?想想电话簿,你想找到所有包含'a'或'rs'或'ems'或其他什么的名字。你如何命令书中的名字快速找到所有这些和所有其他可想象的字母组合?它根本无法完成。
因此,无论您是否提供索引,DBMS都会读取整个表记录以供记录。
可能有一个例外:对于URL和TS的索引,您在索引中都有两列。所以DBMS 可能决定读取整个索引而不是整个表。这可能是有意义的,例如当表有数百列或表非常碎片或其他什么时。我不知道。表通常比索引更容易读取。当然,你仍然可以试试。创建索引并没有什么坏处。 DBMS是否使用它来进行查询。
答案 1 :(得分:1)
在这些任务中,列存储索引可以非常快(全局扫描上的聚合)。但即使他们在处理LIKE '%/mycontroler/%'
谓词时也会遇到问题。我建议您将URL解析为一个额外的计算字段,该字段用于投影URL的提取控制器。但事实是,查看在响应URL上花费的全球时间显示的信息非常少。它将包含自开始以来的数据,早已过时的新部署,并且无法捕获最近的趋势。基于时间的过滤器,例如每小时或每天,现在是一个非常有用的分析。由于自然时间顺序和segment elimination,列存储可以很好地提供这样的过滤器。
答案 2 :(得分:0)
根据您发布的查询,您应该在Url
列上有一个索引。通常,WHERE
,HAVING
,ORDER BY
和JOIN ON
条件中涉及的列应编入索引。
您应该为所述查询获取生成的查询计划,并查看它花费更多时间的位置。再次基于Url
列的数据类型,您可以考虑在该列上使用FULLTEXT
索引