针对每组最大n个SQL查询的高性能方法
[英]High performance approach to greatest-n-per-group SQL query
问题描述
我正在尝试构建一个基础架构，以便按需快速运行回归，从包含Web服务器上所有历史活动的数据库中提取apache请求。 为了通过确保我们仍然回退来自较小客户端的请求来提高覆盖率，我想通过检索每个客户端最多n个（为了这个问题，比如10个）请求来确保请求的分发。
我发现这里回答了一些类似的问题，其中最接近的似乎是SQL查询，以便在一系列ID中返回每个ID的前N行 ，但答案主要是与我已经尝试过的性能无关的解决方案。 例如，row_number（）分析函数可以准确地获取我们正在寻找的数据：
SELECT
*
FROM
(
SELECT
dailylogdata.*,
row_number() over (partition by dailylogdata.contextid order by occurrencedate) rn
FROM
dailylogdata
WHERE
shorturl in (?)
)
WHERE
rn <= 10;
但是，假设此表包含给定日期的数百万条目，并且此方法需要从索引中读取与我们的选择条件匹配的所有行，以便应用row_number分析函数，性能非常糟糕。 我们最终选择了将近一百万行，只是因为他们的row_number超过10而抛弃了绝大多数行。执行上述查询时的统计信息：
|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
|| Id | Operation | Name | Starts | E-Rows | A-Rows | A-Time | Buffers | Reads | Writes | OMem | 1Mem | Used-Mem | Used-Tmp||
|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
|| 0 | SELECT STATEMENT | | 1 | | 12222 |00:09:08.94 | 895K| 584K| 301 | | | | ||
||* 1 | VIEW | | 1 | 4427K| 12222 |00:09:08.94 | 895K| 584K| 301 | | | | ||
||* 2 | WINDOW SORT PUSHED RANK | | 1 | 4427K| 13536 |00:09:08.94 | 895K| 584K| 301 | 2709K| 743K| 97M (1)| 4096 ||
|| 3 | PARTITION RANGE SINGLE | | 1 | 4427K| 932K|00:22:27.90 | 895K| 584K| 0 | | | | ||
|| 4 | TABLE ACCESS BY LOCAL INDEX ROWID| DAILYLOGDATA | 1 | 4427K| 932K|00:22:27.61 | 895K| 584K| 0 | | | | ||
||* 5 | INDEX RANGE SCAN | DAILYLOGDATA_URLCONTEXT | 1 | 17345 | 932K|00:00:00.75 | 1448 | 0 | 0 | | | | ||
|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| |
|Predicate Information (identified by operation id): |
|--------------------------------------------------- |
| |
| 1 - filter("RN"<=:SYS_B_2) |
| 2 - filter(ROW_NUMBER() OVER ( PARTITION BY "DAILYLOGDATA"."CONTEXTID" ORDER BY "OCCURRENCEDATE")<=:SYS_B_2) |
| 5 - access("SHORTURL"=:P1) |
| |
+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
但是，如果我们只查询特定上下文的前10个结果，我们可以更快地执行此操作：
SELECT
*
FROM
(
SELECT
dailylogdata.*
FROM
dailylogdata
WHERE
shorturl in (?)
and contextid = ?
)
WHERE
rownum <= 10;
运行此查询的统计信息：
|-------------------------------------------------------------------------------------------------------------------------|
|| Id | Operation | Name | Starts | E-Rows | A-Rows | A-Time | Buffers ||
|-------------------------------------------------------------------------------------------------------------------------|
|| 0 | SELECT STATEMENT | | 1 | | 10 |00:00:00.01 | 14 ||
||* 1 | COUNT STOPKEY | | 1 | | 10 |00:00:00.01 | 14 ||
|| 2 | PARTITION RANGE SINGLE | | 1 | 10 | 10 |00:00:00.01 | 14 ||
|| 3 | TABLE ACCESS BY LOCAL INDEX ROWID| DAILYLOGDATA | 1 | 10 | 10 |00:00:00.01 | 14 ||
||* 4 | INDEX RANGE SCAN | DAILYLOGDATA_URLCONTEXT | 1 | 1 | 10 |00:00:00.01 | 5 ||
|-------------------------------------------------------------------------------------------------------------------------|
| |
|Predicate Information (identified by operation id): |
|--------------------------------------------------- |
| |
| 1 - filter(ROWNUM<=10) |
| 4 - access("SHORTURL"=:P1 AND "CONTEXTID"=TO_NUMBER(:P2)) |
| |
+-------------------------------------------------------------------------------------------------------------------------+
在这种情况下，Oracle足够聪明，可以在获得10个结果后停止检索数据。 我可以收集一整套上下文并以编程方式生成一个查询，该查询由每个上下文的一个查询实例组成，并将union all整个混乱组合在一起，但考虑到上下文的数量，我们可能会遇到内部Oracle限制，甚至如果不是这样，这种做法就会让人厌恶。
有没有人知道一种方法可以保持第一个查询的简单性，同时保留与第二个查询相称的性能？ 另请注意，我实际上并不关心检索一组稳定的行; 只要它们满足我的标准，它们就可以用于回归。
编辑： Adam Musch的建议奏效了。 由于我不能让他们对他的回答发表评论，因此我将这些更改附加到绩效结果中。 我这次也在使用更大的数据集进行测试，这里是我原来的row_number方法中的（缓存）统计数据，用于比较：
|-------------------------------------------------------------------------------------------------------------------------------------------------|
|| Id | Operation | Name | Starts | E-Rows | A-Rows | A-Time | Buffers | Reads | OMem | 1Mem | Used-Mem ||
|-------------------------------------------------------------------------------------------------------------------------------------------------|
|| 0 | SELECT STATEMENT | | 1 | | 12624 |00:00:22.34 | 1186K| 931K| | | ||
||* 1 | VIEW | | 1 | 1163K| 12624 |00:00:22.34 | 1186K| 931K| | | ||
||* 2 | WINDOW NOSORT | | 1 | 1163K| 1213K|00:00:21.82 | 1186K| 931K| 3036M| 17M| ||
|| 3 | TABLE ACCESS BY INDEX ROWID| TWTEST | 1 | 1163K| 1213K|00:00:20.41 | 1186K| 931K| | | ||
||* 4 | INDEX RANGE SCAN | TWTEST_URLCONTEXT | 1 | 1163K| 1213K|00:00:00.81 | 8568 | 0 | | | ||
|-------------------------------------------------------------------------------------------------------------------------------------------------|
| |
|Predicate Information (identified by operation id): |
|--------------------------------------------------- |
| |
| 1 - filter("RN"<=10) |
| 2 - filter(ROW_NUMBER() OVER ( PARTITION BY "CONTEXTID" ORDER BY NULL )<=10) |
| 4 - access("SHORTURL"=:P1) |
+-------------------------------------------------------------------------------------------------------------------------------------------------+
我冒昧地淡化了亚当的建议; 这是修改后的查询......
select
*
from
twtest
where
rowid in (
select
rowid
from (
select
rowid,
shorturl,
row_number() over (partition by shorturl, contextid
order by null) rn
from
twtest
)
where rn <= 10
and shorturl in (?)
);
...以及来自（缓存）评估的统计数据：
|--------------------------------------------------------------------------------------------------------------------------------------|
|| Id | Operation | Name | Starts | E-Rows | A-Rows | A-Time | Buffers | OMem | 1Mem | Used-Mem ||
|--------------------------------------------------------------------------------------------------------------------------------------|
|| 0 | SELECT STATEMENT | | 1 | | 12624 |00:00:01.33 | 19391 | | | ||
|| 1 | NESTED LOOPS | | 1 | 1 | 12624 |00:00:01.33 | 19391 | | | ||
|| 2 | VIEW | VW_NSO_1 | 1 | 1163K| 12624 |00:00:01.27 | 6770 | | | ||
|| 3 | HASH UNIQUE | | 1 | 1 | 12624 |00:00:01.27 | 6770 | 1377K| 1377K| 5065K (0)||
||* 4 | VIEW | | 1 | 1163K| 12624 |00:00:01.25 | 6770 | | | ||
||* 5 | WINDOW NOSORT | | 1 | 1163K| 1213K|00:00:01.09 | 6770 | 283M| 5598K| ||
||* 6 | INDEX RANGE SCAN | TWTEST_URLCONTEXT | 1 | 1163K| 1213K|00:00:00.40 | 6770 | | | ||
|| 7 | TABLE ACCESS BY USER ROWID| TWTEST | 12624 | 1 | 12624 |00:00:00.04 | 12621 | | | ||
|--------------------------------------------------------------------------------------------------------------------------------------|
| |
|Predicate Information (identified by operation id): |
|--------------------------------------------------- |
| |
| 4 - filter("RN"<=10) |
| 5 - filter(ROW_NUMBER() OVER ( PARTITION BY "SHORTURL","CONTEXTID" ORDER BY NULL NULL )<=10) |
| 6 - access("SHORTURL"=:P1) |
| |
|Note |
|----- |
| - dynamic sampling used for this statement (level=2) |
| |
+--------------------------------------------------------------------------------------------------------------------------------------+
正如所宣传的那样，我们只访问完全过滤行的dailylogdata表。 我担心它似乎仍在根据它声称要选择的行数（1213K）对urlcontext索引进行全面扫描，但考虑到它只使用了6770个缓冲区（即使我这个数字保持不变增加特定于上下文的结果的数量）这可能会产生误导。
4 个解决方案
解决方案1
4 已采纳 2012-03-02 21:52:39
这是一种笨拙的解决方案，但它似乎可以做你想要的：尽快快速索引扫描，而不是读取数据，直到它通过过滤条件和前n个查询条件来限定。
请注意，它使用shorturl =条件进行测试，而不是shorturl IN条件。
with rowid_list as
(select rowid
from (select *
from (select rowid,
row_number() over (partition by shorturl, contextid
order by null) rn
from dailylogdata
)
where rn <= 10
)
where shorturl = ?
)
select *
from dailylogdata
where rowid in (select rowid from rowid_list)
with子句为每个符合条件的shorturl和contextid唯一组合过滤WINDOW NOSORT的前10个rowid。 然后它遍历那组rowid，通过rowid获取每个rowid。
----------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
----------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 286 | 1536 (1)| 00:00:19 |
| 1 | NESTED LOOPS | | 1 | 286 | 1536 (1)| 00:00:19 |
| 2 | VIEW | VW_NSO_1 | 136K| 1596K| 910 (1)| 00:00:11 |
| 3 | HASH UNIQUE | | 1 | 3326K| | |
|* 4 | VIEW | | 136K| 3326K| 910 (1)| 00:00:11 |
|* 5 | WINDOW NOSORT | | 136K| 2794K| 910 (1)| 00:00:11 |
|* 6 | INDEX RANGE SCAN | TABLE_REDACTED_INDEX | 136K| 2794K| 910 (1)| 00:00:11 |
| 7 | TABLE ACCESS BY USER ROWID| TABLE_REDACTED | 1 | 274 | 1 (0)| 00:00:01 |
----------------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
4 - filter("RN"<=10)
5 - filter(ROW_NUMBER() OVER ( PARTITION BY "CLIENT_ID","SCE_ID" ORDER BY NULL NULL
)<=10)
6 - access("TABLE_REDACTED"."SHORTURL"=:b1)
解决方案2
0 2012-02-28 16:04:30
这似乎是一直在采取的那种方式。 是occurrenceDate您的聚集索引，如果没有，是要快得多，如果你改变你的聚集索引订购？ 即如果它是由顺序id聚类，那么按顺序排序。
解决方案3
0 2012-02-28 16:44:14
上次我只是在一个较小的表中缓存了最后一些最有趣的行。 使用我的数据分发，更新每个插入的缓存表而不是查询批量表更便宜。
解决方案4
0 2012-02-28 19:15:49
我认为您还应该检查其他方式/查询以实现相同的结果集。
Self-JOIN / GROUP BY
SELECT
d.*
, COUNT(*) AS rn
FROM
dailylogdata AS d
LEFT OUTER JOIN
dailylogdata AS d2
ON d.contextid = d2.contextid
AND d.occurrencedate >= d2.occurrencedate)
AND d2.shorturl IN (?)
WHERE
d.shorturl IN (?)
GROUP BY
d.*
HAVING
COUNT(*) <= 10
另一个我不知道它是否正常工作：
SELECT
d.*
, COUNT(*) AS rn
FROM
( SELECT DISTINCT
contextid
FROM
dailylogdata
WHERE
shorturl IN (?)
) AS dd
JOIN
dailylogdata AS d
ON d.PK IN
( SELECT
d10.PK
FROM
dailylogdata AS d10
WHERE
d10.contextid = dd.contextid
AND
d10.shorturl IN (?)
AND
rownum <= 10
ORDER BY
d10.occurrencedate
)
在每组最多n个子查询中使用范围过滤器的性能非常差
[英]Using a range filter in a greatest-n-per-group subquery has very poor performance
查询计划差异 inner join/right join "greatest-n-per-group", self joined, aggregated query
[英]Query plan difference inner join/right join "greatest-n-per-group", self joined, aggregated query
声明:本站的技术帖子网页，遵循CC BY-SA 4.0协议，如果您需要转载，请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.
相关问题
SQL - 每组最大的平均数
优化执行缓慢的每组最多n个查询
雅典娜中的SQL语法great-n-per-group +聚合
带关系表联接的SQL great-n-per-group
如何在django中进行“最大n组”查询？
每组最大n条ActiveRecord SQL
MySQL最大的每组麻烦
在每组最多n个子查询中使用范围过滤器的性能非常差
Greatest-n-per-group 查询，包括没有“n”的行
查询计划差异 inner join/right join "greatest-n-per-group", self joined, aggregated query
相关标签