gpt4 book ai didi

sql - 查询并行度高的Oracle表导致全表扫描

转载 作者:行者123 更新时间:2023-12-01 15:16:15 27 4
gpt4 key购买 nike

嗯,标题描述了我最近在使用 Oracle 数据库时遇到的情况。

这是一些背景:

  • 关注的表按哈希分为 4 个分区。
  • table 的平行度为4。
  • 哈希键等于 PK。
  • 表格行数比较多,200M左右。
  • PK 索引也是分区的(本地分区)。
  • 索引的平行度为1。

好的,现在当我更改表的并行度时,查询行为异常。

如果表度为 4,它会导致解释计划显示的全表扫描(协调并行全表扫描)。完成查询需要 30 分钟或更长时间。

如果表度为1-3,则正确使用PK索引(范围扫描,单线程),20秒后返回结果。

如果我将表度和索引度都设置为4,结果是全表扫描(结果与上面第一个场景相同)。

但是,这种行为不会发生在另一个数据库中,在该数据库中我有一个几乎相同的表克隆。唯一的区别是记录的数量。另一个数据库中的表的大小稍小(负 1-2 百万)。较小的表,其度数也为 4,不会遇到具有相同查询的全表扫描。

我花了一些时间在谷歌上搜索,发现了以下有关并行查询的内容:

来自Oracle官方文档

A high degree of parallelism for a table skews the optimizer toward full table scans over range scans. Examine the DEGREE column in ALL_TABLES for the table to determine the degree of parallelism.

来自http://www.toadworld.com/Portals/0/GuyH/Articles/Oracle%20Parallel%20SQL%20Part%201.pdf并行查询应该在什么时候应用

The SQL performs at least one full table, index or partition scan

来自 AskTom.com

Parallel query is suitable for a certain class of large problems: very large problems that have no other solution. Parallel query is my last path of action for solving a performance problem; it's never my first course of action.

并行执行似乎是为在没有其他更好的解决方案时处理超大规模数据而设计的。它试图通过并行运行来提供更好的性能,每个 CPU(进程)专用于处理分离的数据部分( block 范围、表分区或索引分区)。因此它不是为了加速一般查询或未覆盖整个表的足够部分的查询而设计的。

我的上述理解是否正确,不应将并行用作加速一般查询的手段?

如果是,这是否也意味着关闭并行(度数为 0)并通过提示或并行子句为特定查询/操作启用的最佳实践?

除此之外,设置 PARALLEL 的最佳实践应该是什么?如果我想做的是通过多线程提供最佳读取性能,应该如何设置?

这里有很多问题。非常感谢。

最佳答案

一般来说,我同意 Tom 的观点。我们的主基表是一个大约 2.4 亿行的物联网,加上其他索引,每天 24 小时进行 10 到 1,000 次插入、删除和更新操作。我们通常会在几秒钟内从中获取信息,然后如果我们需要大量信息,请进行全面扫描并处理所需的 2.5 小时。在回答您的一些问题时,如果您要做的大查询多于小查询,那么请使用分区。如果没有,那就不要。

关于sql - 查询并行度高的Oracle表导致全表扫描,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/7145712/

27 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com