在进行连接时改进搜索。集群表？

Posted 2023-03-29

【中文标题】在进行连接时改进搜索。集群表？

【英文标题】：Improve search when doing joins. Cluster tables?

【发布时间】：2013-11-14 23:29:38

【问题描述】：

假设我们有三个表： -建筑物 -客房 -人

一栋建筑可以有 1 到 30 个房间（假设平均为 3 个） 一座建筑物可以容纳 0 到 30 人（平均为 3 人） 一个房间和一个人只能属于一个建筑物。

每个月，我们都会在我们的数据库中添加大约 50.000 座新建筑及其房间和人员。 我们可以删除超过 2 年的数据，因此我们将拥有大约 120 万个建筑物行。

主要问题是我们想要搜索并返回通常（但不总是）包含至少两个表（建筑物总是存在）的数据，因此我们必须执行连接。

我研究了 3 个解决方案。

具有标准化数据（由于连接和可扩展性低导致性能低下） 复制房间和人员表中的建筑数据。 （速度很快，但我通常不喜欢非规范化） Oracle 集群表。 （似乎提供了良好的性能，并且数据仍然正常化）

所以问题是： Oracle Cluster 适合这种情况吗？ 这样的Cluster可以连续添加行吗？ 如果您不推荐 Cluster，为什么以及什么更适合？

详情：

集群：

SELECT *
FROM
  (SELECT *
    /*+ FIRST_ROWS(200)*/
  FROM BUILDING_C R
  INNER JOIN PEOPLE_C C
  ON (R.BUILDING_id = C.BUILDING_id)  
  INNER JOIN ROOM_C S
  ON (S.BUILDING_id = R.BUILDING_id)
  WHERE S.OPEN_DATE               >= SYSDATE - 60 -1
  AND S.OPEN_DATE               <= SYSDATE - 60
  ORDER BY S.OPEN_DATE
  )
WHERE rownum < 200;--17 consistent gets

标准化：

SELECT *
FROM
  (SELECT *
    /*+ FIRST_ROWS(200)*/
  FROM BUILDING_N R
  INNER JOIN PEOPLE_N C
  ON (R.BUILDING_id = C.BUILDING_id)  
  INNER JOIN ROOM_N S
  ON (S.BUILDING_id = R.BUILDING_id)
  WHERE S.OPEN_DATE               >= SYSDATE - 60 -1
  AND S.OPEN_DATE               <= SYSDATE - 60
  ORDER BY S.OPEN_DATE
  )
WHERE rownum < 200;--44 consistent gets

【问题讨论】：

非规范化并不邪恶。有时这是必须的。您可以将聚簇表视为在物理级别上进行了非规范化。你提到的卷太大了——1M 的行对于 Oracle 来说不算太多。集群通常用于不能独立“生存”的表，即与其他东西连接起来有一定意义的表。还要注意一些老派 DBA 不喜欢聚簇表，因为它们过去存在一些问题。

您是否调查过您为“低性能”查询获得的执行计划？联接是内在的，因此您说它们是一个问题似乎很奇怪。您是否有适合您正在进行的连接的索引，包括外键？如果没有看到架构、数据、查询和计划，很难猜测为什么它可能比您预期的要慢。

我同意上面的评论。调查执行计划。他们怎么了？您是否使用正确索引的表？您是否考虑过使用位图连接索引 (docs.oracle.com/cd/E11882_01/server.112/e25554/…)？此外，您需要数据的最新程度如何？物化视图是否适用于非规范化表示？

因为有很多数据，我们只需要前 200 个数据，我认为最好的执行计划是嵌套循环。在所有情况下都发生了什么。关于索引，是的，它们是创建的。当您需要过滤位于两个不同表中的数据时，就会出现问题。关于如何“最新”，拥有 2 到 3 秒的复制过程不会成为问题。是的，物化视图可以解决问题，但我不能使用它们（管理禁止）:)

在任何半体面的服务器上，50 毫秒的 3 表连接对这么小的表应该很容易实现。听起来您的问题不是关于您的问题，而是您提出的解决方案。如果你真的问一个关于你的确切问题的问题，那么我相信有人会很容易地提供帮助。至少包括表结构、查询和解释计划以及示例数据。就目前而言，您只会得到通用答案，告诉您使用物化视图或添加索引。最好具体一点……

【参考方案1】：

集群是一种存储密切相关的表的方法，这些表通常连接到磁盘上的同一区域。集群键是在查询中通常用来连接表以节省 IO 的一列或多列。但是，如果单个 Cluster Row 中所有表行的总大小超过一个磁盘块的大小，那么您最终将处于链接状态，并且有一天，您将失去集群的所有优势。在我看来，最好避免，因为考虑到集群中所有 3 个表的滚动量为 1.2 M，这显然会产生 HWM 的影响，这将是一个开销。

最好选择 JOINS。

例如。

CREATE TABLE BUILDING_C ( BUILDING_ID NUMBER PRIMARY KEY,
                     ADDRESS_FIELD VARCHAR2 ( 25 ) );

CREATE TABLE PEOPLE_C ( BUILDING_ID NUMBER PRIMARY KEY,
                    CUSTOMER_ID NUMBER,
                    ROOM_ID NUMBER,
                    CUSTOMER_DETAILS VARCHAR2 ( 25 ) );

CREATE TABLE ROOM_C ( BUILDING_ID NUMBER PRIMARY KEY,
                  ROOM_ID NUMBER,
                  OPEN_DATE DATE,
                  CURRENT_OCCUPANCY CHAR ( 1 ) );

BEGIN
    DBMS_STATS.SET_TABLE_STATS ( OWNNAME     => 'REALSPIRITUALS',
                            TABNAME  => 'BUILDING_C',
                            NUMROWS  => 20000000 );
END;
/

BEGIN
    DBMS_STATS.SET_TABLE_STATS ( OWNNAME     => 'REALSPIRITUALS',
                            TABNAME  => 'PEOPLE_C',
                            NUMROWS  => 20000000 );
END;
/

BEGIN
    DBMS_STATS.SET_TABLE_STATS ( OWNNAME     => 'REALSPIRITUALS',
                            TABNAME  => 'ROOM_C',
                            NUMROWS  => 20000000 );
END;
/

在您的查询中，您的提示不会生效，因为您使用了 SELECT * /*+ FIRST_ROWS(200)*/ 而不是 SELECT /*+ FIRST_ROWS(200)*/ * 所以您最终会使用 OPTIMIZER MODE=ALL_ROWS 而不是 OPTIMIZER MODE=FIRST_ROWS

SET AUTOTRACE ON

SELECT
      *
FROM
      (SELECT
            /*+ FIRST_ROWS(200)*/
            *
       FROM
            BUILDING_C R
            INNER JOIN PEOPLE_C C
                ON ( R.BUILDING_ID = C.BUILDING_ID )
            INNER JOIN ROOM_C S
                ON ( S.BUILDING_ID = R.BUILDING_ID )
       WHERE
            S.OPEN_DATE >=   SYSDATE - 60 - 1
            AND S.OPEN_DATE <= SYSDATE - 60
       ORDER BY
            S.OPEN_DATE)
WHERE
      ROWNUM < 200;


Execution Plan
----------------------------------------------------------
   0       SELECT STATEMENT Optimizer Mode=HINT: FIRST_ROWS (Cost=54189 Card=199 Bytes=38 K)
   1    0    COUNT STOPKEY
   2    1      VIEW (Cost=54189 Card=50 K Bytes=9 M)
   3    2        SORT ORDER BY STOPKEY (Cost=54189 Card=50 K Bytes=9 M)
   4    3          FILTER
   5    4            NESTED LOOPS
   6    5              NESTED LOOPS (Cost=52041 Card=50 K Bytes=9 M)
   7    6                MERGE JOIN (Cost=2020 Card=50 K Bytes=5 M)
   8    7                  TABLE ACCESS BY INDEX ROWID REALSPIRITUALS.BUILDING_C (Cost=826 Card=20 M Bytes=1G)
   9    8                    INDEX FULL SCAN REALSPIRITUALS.SYS_C00504893 (Cost=26 Card=20 M)
  10    7                  SORT JOIN (Cost=1194 Card=50 K Bytes=1 M)
  11   10                    TABLE ACCESS FULL REALSPIRITUALS.ROOM_C (Cost=660 Card=50 K Bytes=1 M)
  12    6                INDEX UNIQUE SCAN REALSPIRITUALS.SYS_C00504894 (Cost=0 Card=1)
  13    5              TABLE ACCESS BY INDEX ROWID REALSPIRITUALS.PEOPLE_C (Cost=1 Card=1 Bytes=91)

Statistics
----------------------------------------------------------
          1  recursive calls
          0  spare statistic 3
          0  gcs messages sent
          0  db block gets from cache
          0  physical reads direct (lob)
          0  queue position update
          0  queue single row
          0  queue ocp pages
          0  HSC OLTP Compressed Blocks
          0  HSC IDL Compressed Blocks
          0  rows processed

建议：

在 OPEN_DATE 列上使用索引 如果需要，使用并行提示来加速 /*+ 并行 (table,n) */ 尝试范围分区

【参考方案2】：

你说“改进搜索”，但是，你真的实现了这个数据模型吗？您是否尝试过一些候选查询？他们的表现是否不够好？ 120 万行对 Oracle 来说是微不足道的。我有几张有数十亿行的表。我认识一个拥有超过 5 trillion 行的分区 IOT。

首先，对所有内容进行规范化，并测试一些候选查询。他们表现如何？如果遇到问题，是否缺少任何索引？您认为什么是足够的性能？

根据我的阅读，如果您无法从具有正确索引集的规范化数据模型中获得令人满意的性能，我会感到非常惊讶。

【讨论】：

我确实以三种方式实现了它并对其进行了基准测试。执行搜索的目标性能不超过 50 毫秒。

一切都符合要求（低于 50 毫秒），直到我需要使用两个表中的数据进行搜索。然后，非规范化和集群保持相同的时间（它可能会上升一些毫秒但不多），但规范化解决方案会达到 200 毫秒。我相信是因为它需要执行两次 IO 来检查两个表的行组合是否正常。

如果您发布 SQL、执行计划以及表现不佳的 SQL 的表和索引定义，将会很有帮助。