oracle- index组织表

Question

what is use-case of IOT ( Index Organized Table ) ?

Let say I have table like

1. id
2. Name
3. surname

i know the IOT but bit confuse about the use case of IOT

Answer 1

Your three columns don't make a good use case.

IOT are most useful when you often access many consecutive rows from a table. Then you define a primary key such that the required order is represented.

A good example could be time series data such as historical stock prices. In order to draw a chart of the stock price of a share, many rows are read with consecutive dates.

So the primary key would be stock ticker (or security ID) and the date. The additional columns could be the last price and the volume.

A regular table - even with an index on ticker and date - would be much slower because the actual rows would be distributed over the whole disk. This is because you cannot influence the order of the rows and because data is inserted day by day (and not ticker by ticker).

In an index-organized table, the data for the same ticker ends up on a few disk pages, and the required disk pages can be easily found.

Setup of the table:

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;

Typical query:

 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.