oracle - oracle-インデックス編成表

Question

IOTのユースケースは何ですか（Index Organized Table）？

私は次のようなテーブルを持っているとしましょう

1. id
2. 名前
3. 姓

私はIOTを知っていますが、のユースケースについて少し混乱していますIOT

Answer 1

3つの列は適切なユースケースにはなりません。

IOTは、テーブルから多数の連続する行に頻繁にアクセスする場合に最も役立ちます。次に、必要な順序が表されるように主キーを定義します。

良い例は、過去の株価などの時系列データです。株式の株価のチャートを描くために、多くの行が連続した日付で読み取られます。

したがって、主キーは株式相場表示（または証券ID）と日付になります。追加の列は、最終価格とボリュームである可能性があります。

通常のテーブル（ティッカーと日付のインデックスがある場合でも）は、実際の行がディスク全体に分散されるため、はるかに遅くなります。これは、行の順序に影響を与えることができず、データが日ごとに挿入されるためです（ティッカーごとではありません）。

インデックス編成のテーブルでは、同じティッカーのデータが数枚のディスクページに表示され、必要なディスクページを簡単に見つけることができます。

テーブルの設定：

CREATE TABLE MARKET_DATA
  (
    TICKER VARCHAR2(20 BYTE) NOT NULL ENABLE,
    P_DATE DATE NOT NULL ENABLE,
    LAST_PRICE NUMBER,
    VOLUME     NUMBER,
    CONSTRAINT MARKET_DATA_PK PRIMARY KEY (TICKER, P_DATE) ENABLE
  )
  ORGANIZATION INDEX;

典型的なクエリ：

 SELECT TICKER, P_DATE, LAST_PRICE, VOLUME
 FROM MARKET_DATA
 WHERE TICKER = 'MSFT'
 AND P_DATE BETWEEN SYSDATE - 1825 AND SYSDATE
 ORDER BY P_DATE;

Answer 2

Think of index organized tables as indexes. We all know the point of an index: to improve access speeds to particular rows of data. This is a performance optimisation of trick of building compound indexes on sub-sets of columns which can be used to satisfy commonly-run queries. If an index can completely satisy the columns in a query's projection the optimizer knows it doesn't have to read from the table at all.

IOTs are just this approach taken to its logical confusion: buidl the index and throw away the underlying table.

There are two criteria for deciding whether to implement a table as an IOT:

1. It should consists of a primary key (one or more columns) and at most one other column. (okay, perhaps two other columns at a stretch, but it's an warning flag).
2. The only access route for the table is the primary key (or its leading columns).

That second point is the one which catches most people out, and is the main reason why the use cases for IOT are pretty rare. Oracle don't recommend building other indexes on an IOT, so that means any access which doesn't drive from the primary key will be a Full Table Scan. That might not matter if the table is small and we don't need to access it through some other path very often, but it's a killer for most application tables.

It is also likely that a candidate table will have a relatively small number of rows, and is likely to be fairly static. But this is not a hard'n'fast rule; certainly a huge, volatile table which matched the two criteria listed above could still be considered for implementations as an IOT.

So what makes a good candidate dor index organization? Reference data. Most code lookup tables are like something this:

code number not null primary key
description not null varchar2(30)

Almost always we're only interested in getting the description for a given code. So building it as an IOT will save space and reduce the access time to get the description.