Question

假设我们有三张桌子：
-Buildings
-Rooms
- 人物

建筑物可以有1到30个房间（比如说平均值是3）建筑物可以有0到30人（平均3人）一个房间和一个人只能属于一个建筑物。

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

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

我研究了3种解决方案。

标准化数据（由于连接和低可伸缩性导致的低性能）
在“房间和人员”表中复制建筑数据。（快但我一般不喜欢非规范化）
Oracle Cluster Tables。（似乎提供了良好的性能，数据仍然正常化）

所以问题是：
Oracle 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

Autotrace output

归一化：

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

Autotrace Output

Answer 1

群集是一种存储密切相关且通常连接在磁盘上相同区域的表的方法。群集密钥是一个或多个列，通过这些列，表通常在查询中连接以保存在IO上。但是，如果单个群集行中所有表行的总大小将超过磁盘块的大小，那么您将最终处于链接状态，并且有一天，您将失去群集的所有优点。在我看来，更好的避免，因为它将是一个开销，因为你有一个1.2 M的滚动量，一个集群中的所有3个表明显会对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列上使用索引
如果需要，可以使用并行提示加速/ * + parallel（table，n）* /
尝试范围分区

Answer 2

你说“改进搜索”，但是，你真的实现了这个数据模型吗？你试过一些候选人的查询吗？他们没有充分表现吗？对于Oracle来说，120万行是花生。我有几张数十亿行的表。我知道有人拥有超过5个万亿行的分区IOT。

首先，规范化所有内容，并测试一些候选查询。他们表现如何？如果您遇到问题，是否遗漏了任何索引？您认为适当的表现是什么？

根据我所读到的内容，如果使用正确的索引集从标准化数据模型中获得满意的性能，我会感到非常惊讶。

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

2 个答案: