CREATE INDEX ステートメント

呼び出し

このステートメントは、アプリケーション・プログラムに組み込んだり、動的 SQL ステートメントを使用して発行したりすることができます。 これは、DYNAMICRULES の実行動作がパッケージに効力を持つ場合にのみ、動的に準備できる実行可能ステートメントです (SQLSTATE 42509)。

許可

宣言済み一時表の索引を作成するのに、明示特権は必要ありません。

構文

注:

• ¹ フェデレーテッド・システムでは、table-name には、フェデレーテッド・データベース内の表を指定します。 データ・ソース表を指定することはできません。
• ² nickname を指定すると、 CREATE INDEX ステートメントは、SPECIFICATION ONLY 指定の索引を作成します。 この場合、INCLUDE、xml-index-specification、CLUSTER、EXTEND USING、PCTFREE、MINPCTUSED、DISALLOW REVERSE SCANS、 ALLOW REVERSE SCANS、PAGE SPLIT、または COLLECT STATISTICS は指定できません。
• ³ BUSINESS_TIME WITHOUT OVERLAPS 節は UNIQUE が指定されている場合のみ指定できます。
• ⁴ IN tablespace-name 節は、パーティション表の非パーティション索引に対してのみ、指定できます。
• ⁵ INCLUDE 節は UNIQUE が指定されている場合のみ指定できます。
• ⁶ xml-index-specification が指定された場合、 column-name DESC、INCLUDE、または CLUSTER は指定できません。

xml-index-specification

注:

• ¹ 代替構文 GENERATE KEYS USING XMLPATTERN が使用できます。

xmlpattern-clause

namespace-declaration

pattern-expression

forward-axis

xmlname-test

xml-wildcard

xmlkind-test

function-step

xmltype-clause

data-type

sql-data-type

注:

• ¹ XML パターンの末尾に fn:upper-case のような関数名を指定した場合、サポートされる索引のデータ・タイプは、ここに示す索引のデータ・タイプのサブセットになる場合があります。 有効な索引のデータ・タイプは、xmlpattern-clause の説明の中で確認できます。

説明

UNIQUE

ON table-name を指定する場合、 UNIQUE により、表には索引キーの値が同じである複数の行を含めることができなくなります。 行の更新、または新しい行の挿入を行う SQL ステートメントの終了時に、固有性が確保されます。

この固有性は、CREATE INDEX ステートメントの実行の過程でも検査されます。 重複するキー値を含む行が既に表に含まれている場合、索引は作成されません。

索引が XML 列にある (つまり索引が XML データに対する索引である) 場合、表のすべての行について、pattern-expression が指定された値に対して固有性が適用されます。 指定された sql-data-type へ値が変換された後、固有性がそれぞれの値に強制されます。 指定された sql-data-type への変換によって精度や範囲に関する欠落が生じることや、異なる値がハッシュ化されたときに同じキー値になる可能性があるので、XML 文書で固有な値に見える値でも「キーが重複している」というエラーになる場合があります。 文字ストリングの固有性は、末尾のブランクも意味を持つ XQuery のセマンティクスに依存しています。 したがって、SQL では重複している値でも、末尾のブランクが異なっているならば、その値は XML データの索引では固有な値と見なされます。

UNIQUE を使用する場合、NULL 値は他の値と同様に扱われます。 例えば、キーが NULL 可能の単一列である場合、 その列では 1 つの NULL 値しか含めることができません。

UNIQUE オプションの指定があり、しかも表に分散キーがある場合、 索引キーの列は分散キーのスーパーセットである必要があります。 つまり、ユニーク索引キーに対して指定される列は、分散キーのすべての列を含んでいる必要があります (SQLSTATE 42997)。

主キーまたはユニーク・キーは、ディメンションのサブセットにはなりません (SQLSTATE 429BE)。

ON nickname が指定されている場合、 索引キーのデータ・ソース表の各行に固有値が含まれている場合に限り、UNIQUE を指定するようにします。 固有性は検査されません。

XML データの索引の場合、UNIQUE は、pattern-expression のコンテキスト・ステップが単一の完全パスを指定し、descendant または descendant-or-self 軸、「//」、xml-wildcard、node()、または processing-instruction() を含まない場合にのみ指定できます (SQLSTATE 429BS)。

パーティション・データベース環境では、1 つ以上の XML 列がある表に以下の規則が適用されます。

• 分散表は、XML データに対するユニーク索引を持つことができません。
• XML データに対するユニーク索引は、分散キーのない、単一ノード複数パーティション・データベース上の表のみでサポートされます。
• XML データに対するユニーク索引が表にある場合、その表に変更を加えて分散キーを追加することはできません。

INDEX index-name

索引または SPECIFICATION ONLY 指定の索引を指定します。 名前 (暗黙または明示の修飾子を含む) は、カタログに記述されている索引または SPECIFICATION ONLY 指定の索引、または宣言済み一時表の既存の索引を指定するものであってはなりません (SQLSTATE 42704)。 修飾子は、SYSIBM、SYSCAT、SYSFUN、または SYSSTAT であってはなりません (SQLSTATE 42939)。

ON table-name または nickname

table-name には、索引を作成する対象の表を指定します。 表は、基本表 (ビューではない) か、作成済み一時表か、宣言済み一時表か、現行のサーバーに存在するマテリアライズ照会表か、または宣言済み一時表でなければなりません。宣言済み一時表の名前は、SESSION によって修飾される必要があります。

table-name には、カタログ表 (SQLSTATE 42832) およびカラム・オーガナイズ表 (SQLSTATE 42858) を指定することはできません。

UNIQUE が指定されており、 table-name が型付き表である場合には、 副表を指定することはできません (SQLSTATE 429B3)。

nickname は、SPECIFICATION ONLY 指定の索引を作成する対象のニックネームです。 この nickname により、索引が SPECIFICATION ONLY 指定の索引によって記述されているデータ・ソース表、 またはそのような表に基づくデータ・ソース・ビューのいずれかが参照されます。 この nickname は、カタログにリストされていなければなりません。

索引キーに少なくとも 1 つの key-expression が含まれている場合、table-name を以下のオブジェクトにすることはできません。

• マテリアライズ照会表 (MQT) (SQLSTATE 429BX)
• ステージング表 (SQLSTATE 429BX)
• 型付き表 (SQLSTATE 429BX)
• 宣言済みまたは作成済みのユーザー一時表 (SQLSTATE 42995)
• イベント・モニターのターゲットである表 (SQLSTATE 429BX)
• ニックネーム (SQLSTATE 42601)

column-name

索引の場合、column-name には索引キーを構成する列を指定します。 SPECIFICATION ONLY 指定の索引の場合、column-name は、 フェデレーテッド・サーバーがデータ・ソース表の列を参照するときの名前になります。

指定期間数の 2 倍に列数を足した値は 64 を超えてはなりません (SQLSTATE 54008)。table-name が型付き表の場合、列の数は 63 を超えることはできません (SQLSTATE 54008)。table-name が副表であるならば、 副表内の少なくとも 1 つの column-name はスーパー表から継承するのではなく、新たに指定する必要があります (SQLSTATE 428DS)。 同じ column-name を使用することはできません (SQLSTATE 42711)。 ランダム順序付けの索引内の列の最大数は、ランダム順序付けで指定した列ごとに 1 つ減ります

指定された列の保管長の合計は、ページ・サイズに対する索引キーの長さの上限を超えてはなりません。 キー長の制限については、『SQL の制限』を参照してください。 table-name が型付き表である場合は、索引キーの長さ制限は 4 バイト減ります。 索引にランダム順序付けがある場合、索引キーの長さはさらに 2 バイト減ります。

この長さは、列のデータ・タイプや NULL 可能か否かによって変動するシステムのオーバーヘッドにより、 より小さい値になることがあります。 この制限に影響を与えるオーバーヘッドの詳細については、『CREATE TABLE』の『バイト・カウント』を参照してください。

列の長さ属性がページ・サイズに対する索引キーの長さの上限を超えない場合でも、LOB 列、または LOB に基づく特殊タイプの列は、索引の一部として使用できません (SQLSTATE 54008)。構造化タイプ列は、EXTEND USING 節も指定されている場合にのみ指定できます (SQLSTATE 42962)。 EXTEND USING 節が指定される場合、列は 1 つしか指定できず、 列のタイプは構造化タイプか、あるいは LOB に基づいていない特殊タイプでなければなりません (SQLSTATE 42997)。

索引が 1 つの列しか持たず、その列が XML データ・タイプを持ち、GENERATE KEY USING XMLPATTERN 節も指定されている場合、索引は XML データの索引になります。 XML データ・タイプを持つ列は、GENERATE KEY USING XMLPATTERN 節も同時に指定されている場合にのみ指定できます (SQLSTATE 42962)。 GENERATE KEY USING XMLPATTERN 節が指定される場合、列は 1 つしか指定できず、列のタイプは XML でなければなりません。

key-expression

以下の制約事項を持つ、スカラー値に対する評価を行わなければならない式を指定します。

• 式は、索引付け可能なスカラー値 (LOB、XML、LONG VARCHAR または LONG VARGRAPHIC は不可) を返さなければなりません (SQLSTATE 429BX)
• 以下のデータ・タイプは、式ベースの索引キーへの入力としてはサポートされません。
  • LONG VARCHAR および LONG VARGRAPHIC (共に非推奨のデータ・タイプ)
  • XML
  • 上にリストされたタイプのいずれかに基づく、ユーザー定義の特殊タイプ
  • データ・タイプ制約が含まれた、ユーザー定義の緩やかに型付けされた特殊タイプ
  • ユーザー定義の構造化タイプおよび参照タイプ
  • 配列、カーソル、および行の各タイプ
• 式には、少なくとも 1 つの列参照が含まれていなければなりません (SQLSTATE 429BX)
• 式には、以下のどれも入れることはできません (SQLSTATE 429BX)。
  • 副照会
  • 集約関数
  • 非 deterministic 関数
  • 外部アクションのある関数
  • ユーザー定義関数
  • テキスト検索関数 (SCORE、CONTAINS など)
  • パーティション・スカラー関数 (HASHEDVALUE など)
  • 動的データ・タイプのスカラー関数 (TYPE_ID、TYPE_NAME、TYPE_SCHEMA など)
  • ホスト変数
  • パラメーター・マーカー
  • シーケンス参照
  • 特殊レジスターおよび特殊レジスターの値に依存する組み込み関数
  • グローバル変数およびグローバル変数の値に依存する組み込み関数
  • TYPE 述部
  • 正規表現関数または REGEXP_LIKE 述部
  • LIKE 述部
  • ストリング・スカラー関数 INSTR、INSTRB、LOCATE、LOCATE_IN_STRING、POSITION、POSSTR
  • OLAP 仕様
  • 有効範囲を持つ参照引数がオブジェクト ID (OID) 列以外の列である、間接参照操作または DEREF 関数
  • SCOPE 節を持つ CAST 指定
  • エラー・トレラントなネストされた表の式

索引キーに少なくとも 1 つの key-expression が含まれている場合、その索引キーは式ベースの索引キーと呼ばれます。

ASC

索引項目が、列の値の昇順で保持されるように指定します。 これがデフォルト設定です。 ASC は、EXTEND USING で定義される索引に指定することはできません (SQLSTATE 42601)。

DESC

索引項目が、列の値の降順で保持されるように指定します。 DESC は、EXTEND USING で定義される索引に指定することはできません。 また、索引が XML データの索引である場合にも指定できません (SQLSTATE 42601)。

RANDOM

索引項目が、列値のランダム順で保持されるように指定します。 RANDOM は、以下のケースでは指定できません。

• EXTENDED USING 節で使用する場合 (SQLSTATE 42613)。
• SPECIFICATION ONLY 節で使用する場合 (SQLSTATE 42613)。
• 宣言済みまたは作成済みグローバル一時表 (DGTT または CGTT) で作成された索引に使用する場合 (SQLSTATE 42995)。
• カラム・オーガナイズ表で作成された索引の場合 (SQLSTATE 42858)。
• CLUSTER オプションが指定されている場合 (SQLSTATE 42613)。
• 列が FOR BIT DATA として宣言されている場合を除き、ICU 照合を使用する CHAR または VARCHAR タイプの索引付き列で使用する場合 (SQLSTATE 42997)。
• ICU 照合を使用する GRAPHIC または VARGRAPHIC タイプの索引付き列で使用する場合 (SQLSTATE 42997)。
• XML タイプの索引付き列で使用する場合 (SQLSTATE 42613)。
• key-expression が含まれている索引で使用する場合 (SQLSTATE 42997)。

BUSINESS_TIME WITHOUT OVERLAPS

BUSINESS_TIME WITHOUT OVERLAPS は、UNIQUE として定義された索引に対してのみ指定できます (SQLSTATE 428HW)。これは、残りの指定キーの値が、任意の期間においてユニークになることを示します。 BUSINESS_TIME WITHOUT OVERLAPS は、リストの最後の項目としてのみ指定できます。 BUSINESS_TIME WITHOUT OVERLAPS を指定すると、期間 BUSINESS_TIME の終了列および開始列が自動的に昇順で索引キーに追加され、時間の重なり合いがないように強制されます。BUSINESS_TIME WITHOUT OVERLAPS を指定する際は、期間 BUSINESS_TIME の列をキー列として、パーティション・キーの列として、または分散キーの列として指定することはできません (SQLSTATE 428HW)。

PARTITIONED

パーティション索引を作成する必要があることを示します。 table-name は、データ・パーティションを指定して定義されている表を示していなければなりません (SQLSTATE 42601)。

表がパーティション化されており、PARTITIONED と NOT PARTITIONED がどちらも指定されていない場合、索引はパーティション化されたものとして作成されます (例外が幾つかあります)。 以下のいずれかの状態が当てはまる場合には、非パーティション索引がパーティション索引の代わりに作成されます。

• UNIQUE が指定されており、かつ索引キーにすべての表パーティション・キー列が含まれているわけではない。
• 空間インデックスが作成されている。

非パーティション索引の定義と重複する定義を持つパーティション索引は、重複索引とは見なされません。 詳しくは、このトピックにある規則というセクションを参照してください。

PARTITIONED キーワードは、以下の索引には指定できません。

• 非パーティション表上の索引 (SQLSTATE 42601)
• 索引キーにすべての表パーティション・キー列が明示的に含まれているわけではないユニーク索引 (SQLSTATE 42990)
• 空間インデックス (SQLSTATE 42997)

MQT などの、デタッチされた従属表のあるパーティション表上にはパーティション索引を作成できません (SQLSTATE 55019)。

パーティション索引の索引パーティションの表スペース配置は、以下の規則に従って判別されます。

• CREATE TABLE ステートメントの INDEX IN 節の partition-tablespace-options を使用して、索引化している表が作成された場合、その INDEX IN 節で指定された表スペース内に索引パーティションが作成されます。
• 索引化している表の CREATE TABLE ステートメントの INDEX IN 節に partition-tablespace-options が指定されていない場合は、索引化されている対応するデータ・パーティションと同じ表スペース内に、索引パーティションのパーティション索引が作成されます。

CREATE INDEX ステートメントの IN 節では、パーティション索引はサポートされていません (SQLSTATE 42601)。 CREATE TABLE ステートメントの INDEX IN 節の tablespace-clauses は、パーティション索引では無視されます。BUSINESS_TIME WITHOUT OVERLAPS が索引キーに指定されている場合、パーティション・キー列に期間 BUSINESS_TIME の開始列または終了列が含まれていてはなりません (SQLSTATE 428HW)。

NOT PARTITIONED

非パーティション索引が、表に関して定義されたすべてのデータ・パーティションにわたって作成されることを指定します。table-name は、データ・パーティションを指定して定義されている表を示していなければなりません (SQLSTATE 42601)。

パーティション索引の定義と重複する定義を持つ非パーティション索引は、重複索引とは見なされません。 詳しくは、このトピックにある規則というセクションを参照してください。

非パーティション索引の表スペース配置は、以下の規則に従って判別されます。

• CREATE INDEX ステートメントの IN 節を指定した場合、非パーティション索引はその IN 節で指定された表スペースに配置されます。
• CREATE INDEX ステートメントの IN 節を指定しない場合には、非パーティション索引の表スペース配置は以下の規則に従って判別されます。
  • 索引化されている表が CREATE TABLE ステートメントの INDEX IN 節の tablespace-clauses を使用して作成された場合、その INDEX IN 節で指定された表スペースに非パーティション索引が配置されます。
  • 索引化されている表が CREATE TABLE ステートメントの INDEX IN 節の tablespace-clauses を使用しないで作成された場合、その表の最初の可視または接続済みデータ・パーティションにある表スペース内に非パーティション索引が作成されます。 表の最初の可視または接続済みデータ・パーティションとは、範囲指定に基づいてソートされたデータ・パーティションのリスト中の最初のパーティションです。 また、ステートメントの許可 ID にはデフォルトの表スペースに対する USE 特権は必要ありません。

IN tablespace-name

パーティション表に対する非パーティション索引を作成する表スペースを指定します。 この節は、パーティション索引および非パーティション表の索引には 指定できません (SQLSTATE 42601)。索引に専用の表スペースを指定すると、 表の作成時に INDEX IN 節を使用して行った指定は、オーバーライドされます。

tablespace-name で指定する表スペースは、表のデータ表スペースと同じデータベース・パーティション・グループになければならず、パーティション表の他の表スペースと同じスペース管理方式でなければなりません (SQLSTATE 42838)。ステートメントの許可 ID には、その表スペースに対する USE 特権が必要です。

IN 節が指定されない場合、索引は CREATE TABLE ステートメントの INDEX IN 節で指定された表スペースに作成されます。 INDEX IN 節が指定されなかった場合、表のデータ・パーティションのうち、最初の可視パーティションまたはアタッチされたパーティションの表スペースが使用されます。 これは、範囲指定に基づいてソートされたデータ・パーティションのリスト中の最初のパーティションです。 IN 節が指定されなければ、ステートメントの許可 ID にはデフォルトの表スペースに対する USE 特権は必要ありません。

SPECIFICATION ONLY

nickname で参照するデータ・ソース表に適用される、SPECIFICATION ONLY 指定の索引を作成するために、このステートメントが使われることを示します。 SPECIFICATION ONLY は、nickname を指定した場合に、指定しなければなりません (SQLSTATE 42601)。 table-name を指定した場合には、指定することはできません (SQLSTATE 42601)。

SPECIFICATION ONLY 指定の索引がユニーク索引に適用される場合、データベース・マネージャーは、リモート表内の列値が固有であるかどうかを検査しません。リモート列値が固有でない場合、索引列を含むニックネームに対する照会が、誤ったデータやエラーを戻す可能性があります。

作成済み一時表または宣言済み一時表の索引が作成される場合には、この節は使用できません (SQLSTATE 42995)。

INCLUDE

このキーワードは、一連の索引キー列に追加する列を指定する節を、新たに指定します。 この節によって組み込まれる列は、固有性を強制するために使用されることはありません。 これらの組み込み列を使用して、索引のみのアクセスを実行することにより、 一部の照会のパフォーマンスが向上する可能性があります。 この列は、固有性を強制するために使用される列とは 区別する必要があります (SQLSTATE 42711)。 INCLUDE が指定された場合には、UNIQUE を指定する必要があります (SQLSTATE 42613)。 列の数および長さ属性の合計に対する制限は、 ユニーク・キーと索引にあるすべての列にも適用されます。

この節は、作成済み一時表や宣言済み一時表には使用できません (SQLSTATE 42995)。

column-name

索引には組み込まれているものの、ユニーク索引キーの一部ではない列を指定します。 ユニーク索引キーの列に定義された規則と同様の規則が適用されます。 column-name の後にキーワード ASC、DESC、または RANDOM を指定できますが、順序には影響しません。

key-expression

索引には組み込まれているものの、ユニーク索引キーの一部ではない式を指定します。 ユニーク索引キーの式に定義された規則と同様の規則が適用されます。key-expression の後にキーワードの ASC、DESC、または RANDOM を指定できますが、順序には影響しません。

INCLUDE は、EXTEND USING で定義される索引に指定することはできません。 nickname が指定されている場合、また索引が XML 列で定義されている場合にも指定できません (SQLSTATE 42601)。

xml-index-specification

XML 列に保管された XML 文書からどのように索引キーが生成されるかを指定します。 xml-index-specification は、索引列が複数存在する場合、または列が XML データ・タイプを持たない場合は、指定できません。

この節は、XML 列にのみ適用されます (SQLSTATE 429BS)。

GENERATE KEY USING XMLPATTERN xmlpattern-clause

索引の対象となる XML 文書の部分を指定します。 XML パターン値は、xmlpattern-clause によって生成される索引付け対象値です。 リスト・データ・タイプのノードは索引ではサポートされていません。 ノードが xmlpattern-clause によって修飾され、そのノードがリスト・データ・タイプであることを示す XML スキーマが存在している場合、このリスト・データ・タイプのノードを索引付けすることはできません (CREATE INDEX ステートメントでは SQLSTATE 23526、または INSERT および UPDATE ステートメントでは SQLSTATE 23525)。

xmlpattern-clause

索引の対象となるノードを特定するパターン式が入ります。 オプションの namespace-declaration と必須の pattern-expression で構成されます。

namespace-declaration

パターン式に修飾名が含まれている場合は、namespace-declaration を指定して名前空間接頭部を定義する必要があります。 非修飾名には、デフォルトの名前空間を定義できます。

DECLARE NAMESPACE namespace-prefix=namespace-uri

NCName である namespace-prefix を、ストリング・リテラルである namespace-uri にマップします。namespace-declaration には、複数の namespace-prefix から namespace-uri へのマッピングを含めることができます。 namespace-prefix は、namespace-declaration のリストの中で固有でなければなりません (SQLSTATE 10503)。

DECLARE DEFAULT ELEMENT NAMESPACE namespace-uri

非修飾の要素名またはタイプに対するデフォルトの名前空間 URI を宣言します。 デフォルトの名前空間が宣言されない場合、要素やタイプの非修飾名はどの名前空間にも属さないことになります。 宣言できるデフォルトの名前空間は 1 つだけです (SQLSTATE 10502)。

pattern-expression

XML 文書内の、索引の対象となるノードを指定します。 pattern-expression には、パターン・マッチング文字 (*) を入れることができます。

/ (スラッシュ)

パス式のステップを分離します。

// (二重スラッシュ)

これは、/descendant-or-self::node()/ の短縮構文です。 // (二重スラッシュ) は、UNIQUE を指定した場合は使用できません。

forward-axis

child::

コンテキスト・ノードの子を指定します。 これは、他のフォワード軸が指定されない場合のデフォルトです。

@

コンテキスト・ノードの属性を指定します。 これは、attribute:: の短縮構文です。

attribute::

コンテキスト・ノードの属性を指定します。

descendant::

コンテキスト・ノードの子孫を指定します。 descendant:: は、UNIQUE を指定した場合は使用できません。

self::

コンテキスト・ノード自体を単独で指定します。

descendant-or-self::

コンテキスト・ノードとそのコンテキスト・ノードの子孫を指定します。 descendant-or-self:: は、UNIQUE を指定した場合は使用できません。

xmlname-test

パス内のステップに、XML の修飾名 (xml-qname) またはワイルドカード (xml-wildcard) を使用してノード名を指定します。

xml-ncname

XML 1.0 で定義された XML 名。 コロン文字を組み込むことはできません。

xml-qname

以下の 2 とおりの形式のいずれかで XML の修飾名 (QName としても知られる) を指定します。

• xml-nsprefix:xml-ncname。xml-nsprefix は、有効範囲内名前空間を特定する xml-ncname。
• xml-ncname。暗黙の xml-nsprefix としてデフォルトの名前空間が適用されるよう指定する。

xml-wildcard

xml-qname を、以下の 3 とおりの形式のいずれかでワイルドカードとして指定します。

• * (単一のアスタリスク文字)。これは、あらゆる xml-qname に対応する。
• xml-nsprefix:*。これは、指定の名前空間内のあらゆる xml-ncname に対応する。
• *:xml-ncname。これは、あらゆる有効範囲内名前空間の特定の XML 名に対応する。

UNIQUE も指定する場合、パターン式のコンテキスト・ステップで xml-wildcard を使用することはできません。

xmlkind-test

これらのオプションは、パターン・マッチングするノードのタイプを指定するのに使用します。 ユーザーは以下のオプションを使用できます。

node()

あらゆるノードに一致します。 node() は、UNIQUE を指定した場合は使用できません。

text()

あらゆるテキスト・ノードに一致します。

comment()

あらゆるコメント・ノードに一致します。

processing-instruction()

あらゆる処理命令ノードに一致します。 processing-instruction() は、UNIQUE を指定した場合は使用できません。

function-step

これらの関数呼び出しは、大/小文字の区別なしなど、特殊なプロパティーを持つ索引を指定する場合に使用します。 XMLPATTERN 節ごとに 1 つの関数ステップしか許可されません。 関数ステップは、エレメントまたは属性にのみ適用できます。 関数ステップの直前に xmlkind-test オプションを配置することはできません。 関数は、XMLPATTERN の途中では使用できず、最終ステップでのみ使用できます。 現行では、fn:upper-case 関数と fn:exists 関数のみがサポートされています。

関数名として接頭部 fn: を指定する代わりに、別の有効なネーム・スペースを指定することもできますし、fn: を完全に省略することもできます。

fn:upper-case

強制的に索引値を大文字形式で格納します。 fn:upper-case の最初のパラメーターは必須で、コンテキスト項目式 (' . ') でなければなりません。2 番目のパラメーターはロケールで、これはオプションです。 fn:upper-case がパターンに出現する場合、サポートされる索引タイプは VARCHAR および VARCHAR HASHED のみです。

fn:exists

XML 文書内でエレメント項目または属性項目があるかどうかを検査します。 項目が存在する場合、この述部は TRUE を返します。 fn:exists のパラメーターは必須で、エレメントまたは属性でなければなりません。 この関数が索引パスで使用される場合、索引タイプは VARCHAR(1) として定義する必要があります。

xmltype-clause

AS data-type

索引値を保管前に変換するデータ・タイプを指定します。 値は、指定した索引 SQL データ・タイプに対応する索引 XML データ・タイプに変換されます。

表 1. 対応する索引データ・タイプ

索引 XML データ・タイプ	索引 SQL データ・タイプ
xs:string	VARCHAR(integer)、VARCHAR HASHED
xs:double	DOUBLE
xs:int	INTEGER
xs:decimal	DECIMAL
xs:date	DATE
xs:dateTime	TIMESTAMP

VARCHAR(integer) および VARCHAR HASHED の場合、値は、XQuery 関数 fn:string を使用して xs:string 値に変換されます。 VARCHAR(integer) の長さ属性は、変換後の xs:string 値に対する制約として適用されます。 VARCHAR HASHED の索引 SQL データ・タイプは、ハッシュ・アルゴリズムを変換後の xs:string 値に適用し、索引に挿入されるハッシュ・コードを生成します。

データ・タイプ DOUBLE、DATE、INTEGER、DECIMAL、および TIMESTAMP を使用する索引の場合、この値は、XQuery キャスト式を使用して索引 XML データ・タイプに変換されます。

索引が固有であれば、索引のタイプに値が変換された後、値は必ず固有になります。

data-type

以下のデータ・タイプがサポートされています。

sql-data-type

サポートされる SQL データ・タイプは以下のとおりです。

VARCHAR(integer[OCTETS])

この書式の VARCHAR が指定されると、integer が制約として使用されます。 索引付けされる文書ノードに、integer より長い値があれば、索引が既に存在する場合、文書は表に挿入されません。 索引が存在しない場合、索引は作成されません。 integer は、1 とページ・サイズ依存の最大値の間の値です。 ページ・サイズごとの最大値は、表 2 のようになります。

表 2. ページ・サイズごとの文書ノードの最大長

ページ・サイズ	文書ノードの最大長 (単位: バイト)
4KB	817
8KB	1841
16KB	3889
32KB	7985

XQuery セマンティクスがストリングの比較に使用されますが、この場合末尾ブランクも意味を持ちます。 これは、SQL セマンティクス (比較時に末尾ブランクが無視される) とは異なっています。

OCTETS

長さ属性の単位がバイトであることを指定します。

Unicode データベース内で、ストリング単位が文字ストリング・データ・タイプに指定されない場合、ストリング単位は暗黙的で、 NLS_STRING_UNITS グローバル変数または string_units データベース構成パラメーターの値によって決定されます。 暗黙的ストリング単位が CODEUNITS32 の場合、OCTETS キーワードを指定する必要があります (SQLSTATE 42601)。

Unicode 以外のデータベースでは、文字ストリング・データ・タイプのストリング単位は OCTETS です。

VARCHAR HASHED

任意の長さの文字ストリングの索引作成を扱う VARCHAR HASHED を指定します。 索引にされるストリングの長さには制限はありません。 ストリング全体に対して 8 バイトのハッシュ・コードが生成されます。 これらのハッシュされた文字ストリングを使用する索引は、同等性検索にのみ使用できます。 XQuery セマンティクスが、ストリングの等価比較に使用されますが、この場合末尾ブランクは意味を持ちます。これは、SQL セマンティクス (比較時に末尾ブランクが無視される) とは異なっています。 ストリング上のハッシュは、等価の XQuery セマンティクスを保持しますが、SQL セマンティクスは保持しません。

DOUBLE

データ・タイプ DOUBLE が数値の索引作成に使用されるよう指定します。 無制限の DECIMAL タイプと 64 ビットの整数は、DOUBLE 値として保存される場合、精度を失う場合があります。 DOUBLE の値には、特別な数値 NaN、INF、-INF、+0、および -0 を含めることができます。ただし、SQL データ・タイプ DOUBLE 自体はこれらの値をサポートしていません。

INTEGER

データ・タイプ INTEGER が XML 値の索引作成に使用されるよう指定します。 xs:integer の XML スキーマ・データ・タイプは、整数の SQL データ・タイプより広範囲の値を許容することに注意してください。 範囲外の値が検出されると、エラーが戻されます。値が xs:double の字句形式に準拠するものの、xs:int の字句形式には準拠しない場合 (3.5、3.0、3E1 など)、エラーも返されます。

DECIMAL(integer, integer)

データ・タイプ DECIMAL が XML 値の索引作成に使用されるよう指定します。 DECIMAL タイプは、precision と scale という 2 つのパラメーターを取ります。 最初のパラメーター precision は、総桁数を指定する、1 から 31 の範囲の値を持つ整数定数です。 2 番目のパラメーター scale は、ゼロ以上で precision 以下の整数定数です。 scale は、小数点より右側の数字の桁数を指定します。

10 進数の末尾から桁が切り捨てられることはありません。 小数点文字より右側の数字の桁数が scale より多い場合、エラーが返されます。 また、小数点文字の左側にある有効数字 (数値の整数部分) の桁数が precision よりも多い場合は、エラーが返されます。

DATE

データ・タイプ DATE が XML 値の索引作成に使用されるよう指定します。 xs:date の XML スキーマ・データ・タイプは、SQL データ・タイプに対応する pureXML® xs:date データ・タイプよりも広範囲の値を許容することに注意してください。範囲外の値が検出されると、エラーが戻されます。

TIMESTAMP

データ・タイプ TIMESTAMP が XML 値の索引作成に使用されるよう指定します。 xs:dateTime の XML スキーマ・データ・タイプは、SQL データ・タイプに対応する pureXML xs:dateTime データ・タイプよりも広範囲の値および秒未満の精度を許容することに注意してください。範囲外の値が検出されると、エラーが戻されます。

IGNORE INVALID VALUES

これを指定すると、ターゲット索引の XML データ・タイプで字句形式が無効な XML パターン値は無視され、格納されている XML 文書内の対応する値の索引は CREATE INDEX ステートメントによって生成されません。 デフォルトでは、無効値は無視されます。挿入と更新の操作では、無効な XML パターン値の索引は生成されませんが、XML 文書は表に挿入されます。 このようなデータ・タイプを指定しても XML パターン値の制約とは見なされないので、エラーや警告にはなりません (特定の XML 索引データ・タイプを検索する XQuery 式は、それらの値を処理の対象にしません)。

どの XML パターン値を無視できるかについての規則は、指定 SQL データ・タイプによって決まります。

• SQL データ・タイプが VARCHAR(integer) または VARCHAR HASHED である場合、すべての文字シーケンスが有効であるため、XML パターン値が無視されることはありません。
• SQL データ・タイプが DOUBLE、DECIMAL、または INTEGER である場合、XML データ・タイプ xs:double の字句形式に準拠しない XML パターン値は無視されます。 SQL データ・タイプが DECIMAL または INTEGER で、XML パターン値が XML データ・タイプ xs:double の字句形式には準拠するものの、それぞれ xs:decimal または xs:int の字句形式には準拠しない場合、エラーが返されます。 例えば、SQL データ・タイプが INTEGER である場合、XML パターン値 3.5、3.0、および 3e0 は xs:double の字句形式には準拠するものの、xs:int の字句形式には準拠しないため、エラーが返されます (SQLSTATE 23525)。 「A123」、「hello」などの XML パターン値は、同じ索引において無視されます。
• SQL データ・タイプが datetime データ・タイプである場合、対応する XML データ・タイプの字句形式 (xs:date または xs:dateTime) に準拠しない XML パターン値は無視されます。

XML パターン値が該当する字句形式に準拠する場合、値がそのデータ・タイプの値スペースの外部にあるか、指定した SQL データ・タイプの最大長または最大精度、および位取りを超えると、エラーが返されます。 索引が存在しない場合、索引は作成されません (SQLSTATE 23526)。

REJECT INVALID VALUES

索引の XML データ・タイプの字句定義のコンテキストでは、すべての XML パターン値が有効でなければなりません。 また、値は、索引の XML データ・タイプの値スペースの範囲に含まれていなければなりません。 各データ・タイプの字句定義および値スペースの詳細を示すリンクについては、下記の『関連資料』セクションを参照してください。 例えば、REJECT INVALID VALUES 節を指定するときに INTEGER タイプの索引を作成する場合、3.5、3.0、3e0、「A123」、「hello」などの XML パターン値ではエラーが返されます (SQLSTATE 23525)。 索引が既に存在していれば、XML データが表に挿入されたり、表の中で更新されたりすることはありません (SQLSTATE 23525)。索引が存在しない場合、索引は作成されません (SQLSTATE 23526)。

CLUSTER

索引を表のクラスター索引として指定します。 クラスター索引のクラスター係数は、 関連する表にデータが挿入されるときに、動的に保守され適切な値に調整されます。 これは、この索引のキー値が同じ範囲にある行と物理的に近い位置に、 新しい行の挿入を試みることによって行われます。 ただし、表のクラスター索引は 1 つだけなので、 CLUSTER が表の既存の索引の定義に使用されていて、 CLUSTER が指定できないということもありえます (SQLSTATE 55012)。 追加モードを使用するように定義されている表では、 クラスター索引を作成できない場合があります (SQLSTATE 428D8)。

CLUSTER は、nickname が指定されている場合、または索引が XML データの索引である場合は使用できません (SQLSTATE 42601)。

この節は、以下のタイプの表では使用できません。

• 作成済み一時表や宣言済み一時表 (SQLSTATE 42995)
• 範囲がクラスター化された表 (SQLSTATE 429BG)

EXTEND USING index-extension-name

この索引を管理するのに使用する index-extension を指定します。 この節を指定する場合、1 つだけ column-name を指定しなければならず、 この列は構造化タイプまたは特殊タイプでなければなりません (SQLSTATE 42997)。 index-extension-name (索引拡張名) は、カタログに記述されている索引拡張を指定する名前でなければなりません (SQLSTATE 42704)。 特殊タイプの場合には、列が、 索引拡張でソース・キー・パラメーターに対応するタイプと完全に一致していなければなりません。 構造化タイプ列では、対応するソース・キー・パラメーターのタイプが、 列タイプのタイプまたはスーパータイプと同じでなければなりません (SQLSTATE 428E0)。

この節は、作成済み一時表や宣言済み一時表には使用できません (SQLSTATE 42995)。

この節は、索引キーに少なくとも 1 つの key-expression が含まれている場合には使用できません (SQLSTATE 42601)。

constant-expression

索引拡張に必要な引数の値を指定します。 各式は、対応する索引拡張パラメーターの定義されたデータ・タイプ (長さまたは精度、 およびスケールも含む) に完全に一致するデータ・タイプを持つ定数値でなければなりません (SQLSTATE 428E0)。 この節は、データベース・コード・ページ内で、32 768 バイト以内の長さでなければなりません (SQLSTATE 22001)。

PCTFREE integer

索引を構築する際に、各索引ページで何 % をフリー・スペースとして残すかを指定します。 ページの最初の項目は、制限なしで追加されます。 索引ページに項目を追加する場合には、 各ページに少なくとも integer パーセントをフリー・スペースとして残します。 integer の値は 0 から 99 です。 10 よりも大きな値を指定しても、 非リーフ・ページには 10% のフリー・スペースしか残されません。

PCTFREE の明示的な値が指定されず、Db2_INDEX_PCTFREE_DEFAULT が設定されていない場合、PCTFREE のデフォルト値が 10 になります。

PCTFREE は、nickname が指定されている場合は使用できません (SQLSTATE 42601)。 この節は、作成済み一時表や宣言済み一時表には使用できません (SQLSTATE 42995)。

LEVEL2 PCTFREE integer

索引を作成する際に、索引レベル 2 の各ページで何 % をフリー・スペースとして残すかを指定します。 integer の値は 0 から 99 です。 LEVEL2 PCTFREE が設定されない場合は、 すべての非リーフ・ページに最低 10 % または PCTFREE で指定された分 (%) のフリー・スペースが残されます。 LEVEL2 PCTFREE が設定された場合は、 integer で指定された分 (%) のフリー・スペースがレベル 2 の中間ページに残され、 レベル 3 以上の中間ページには最低 10 % または integer で指定された分 (%) のフリー・スペースが残されます。

nickname が指定されている場合は、LEVEL2 PCTFREE は使用できません (SQLSTATE 42601)。 この節は、作成済み一時表や宣言済み一時表には使用できません (SQLSTATE 42995)。

MINPCTUSED integer

索引のリーフ・ページをオンラインでマージするかどうか、 および索引のリーフ・ページで使用されるスペースの最小パーセンテージの限界値を指定します。 索引のリーフ・ページからキーを除去した後、 そのページで使用されているスペースのパーセントが integer のパーセントを下回る場合、 このページにある残りのキーを近隣のページのキーにマージするよう試行されます。 いずれかのページに十分なスペースがあれば、マージが行われ、いずれかのページが削除されます。 integer の値は 0 から 99 です。 パフォーマンス上の理由のため、50 以下の値をお勧めします。 このオプションを指定すると、更新および削除のパフォーマンスに影響があります。排他的表ロックが掛けられている場合、更新および削除操作の実行中に限りマージされます。排他的表ロックがない場合には、 更新および削除操作の間にキーは疑似的に削除されたものとしてマークされ、マージは実行されません。リーフ・ページをマージするには、CREATE INDEX の MINPCTUSED を使うのではなく、 REORG INDEXES の CLEANUP ONLY ALL オプションを使用することを考慮してください。

MINPCTUSED は、nickname が指定されている場合は使用できません (SQLSTATE 42601)。 この節は、作成済み一時表や宣言済み一時表には使用できません (SQLSTATE 42995)。

DISALLOW REVERSE SCANS

索引において、前方向スキャン、 すなわち索引作成時に定義された順序でのスキャンだけをサポートすることを指定します。

DISALLOW REVERSE SCANS は nickname と同時には指定できません (SQLSTATE 42601)。

ALLOW REVERSE SCANS

索引が前方向スキャンと反対方向スキャンの両方、すなわち、 索引作成時に定義された順序での索引のスキャンと、 その反対の順序でのスキャンをサポートすることを指定します。

ALLOW REVERSE SCANS は nickname と同時には指定できません (SQLSTATE 42601)。

PAGE SPLIT

索引に値を挿入する際のページ分割動作を指定します。デフォルトは SYMMETRIC です。

SYMMETRIC

ページを大まかに半分で分割するよう指定します。 このオプションは、以下の状況で使用します。

• 索引への挿入がランダムである場合
• 索引への挿入が、PAGE SPLIT HIGH オプションおよび PAGE SPLIT LOW オプションで対処できるパターンに従っていない場合

HIGH

増加し続ける値が索引にある場合に索引ページ上のスペースを効率的に使用する、索引ページ分割動作を指定します。以下の条件が満たされる場合、増加していく値が索引に存在する可能性があります。

• 索引が複数のキー部分で構成されていて、最後のキー部分以外はすべて値が同じ、という索引ページが複数存在する。
• 表へのすべての挿入操作が、最後のキー部分以外はすべて既存のキーと値が同じ、という新しい値で構成されている。
• 挿入された値の最後のキー部分が、既存のキーの値より大きい。

例えば、索引に次のキー値があるとします。

   (1,1),(1,2),(1,3), ... (1,n),
   (2,1),(2,2),(2,3), ... (2,n),
   ...
   (m,1),(m,2),(m,3), ... (m,n)

次に挿入するキーの値は (x,y) (1 <= x <= m かつ y > n) だとします。

このような場合、ページ分割によって 50 % が空のページが多くならないように、PAGE SPLIT HIGH 節を使用します。

LOW

減少し続ける値が索引にある場合に索引ページ上のスペースを効率的に使用する、索引ページ分割動作を指定します。以下の条件が満たされる場合に、減少していく値が索引に存在する可能性があります。

• 索引が複数のキー部分で構成されていて、最後のキー部分以外はすべて値が同じ、という索引ページが複数存在する。
• 表へのすべての挿入操作が、最後のキー部分以外はすべて既存のキーと値が同じ、という新しい値で構成されている。
• 挿入された値の最後のキー部分が、既存のキーの値より小さい。

このような場合、ページ分割によって 50 % が空のページが多くならないように、PAGE SPLIT LOW 節を使用します。

COLLECT STATISTICS

索引の作成時に基本索引統計が収集されるように指定します。

SAMPLED

これを指定すると、索引項目を処理して拡張索引統計を収集するときに、サンプリング技法が使用されます。 このオプションは、パフォーマンスの考慮と正確な統計を取る必要性の間でバランスを取るために使用されます。 キーワード COLLECT の直後に DETAILED が指定されている場合、このオプションはデフォルトです。

UNSAMPLED

これを指定すると、索引項目を処理して拡張索引統計を収集するときに、サンプリングが使用されません。 代わりに、各索引項目は個別に検査されます。 このオプションを使用すると、CPU とメモリーの使用量がかなり増加します。

DETAILED

索引の作成時に、拡張索引統計 (CLUSTERFACTOR および PAGE_FETCH_PAIRS) も収集されるように指定します。

COMPRESS

索引圧縮が使用可能かどうかを示します。 デフォルトでは、データ行圧縮が使用可能な場合、または表が宣言済みグローバル一時表 (DGTT) か作成済みグローバル一時表 (CGTT) である場合は、索引圧縮も使用可能になります。一方、データ行圧縮が使用不可の場合は、索引圧縮も使用不可になります。 このオプションを使用して、デフォルト動作をオーバーライドできます。COMPRESS は、nickname が指定されている場合は使用できません (SQLSTATE 42601)。

YES

索引圧縮を使用可能にすることを指定します。索引に対する挿入と更新の操作で、圧縮が行われるようになります。

NO

索引圧縮を使用不可にすることを指定します。

INCLUDE NULL KEYS

索引キーのすべての部分に NULL 値が含まれている場合に、索引項目が作成されることを指定します。 これはデフォルト設定です。

EXCLUDE NULL KEYS

索引キーのすべての部分に NULL 値が含まれている場合に、索引項目が作成されないことを指定します。 索引キーのいずれかの部分が NULL 値でない場合、索引項目は作成されます。 EXCLUDE NULL KEYS は、以下の構文要素では指定できません。

• ニックネーム
• GENERATE KEY USING XMLPATTERN 節
• EXTEND USING 節

索引がユニークで定義されている場合、固有性の強制時には、NULL キーのある行は考慮されません。

規則

• 既存の索引に一致する索引を作成しようとすると、CREATE INDEX ステートメントはエラーになります (SQLSTATE 01550)。
  多数の要因を使用して、2 つの索引が一致するかどうかが判別されます。これらの要因は、さまざまな方法で、2 つの索引が一致するかどうかを判別する規則に結合されます。以下の要因を使用して、2 つの索引が一致するかどうかが判別されます。

  1. INCLUDE 列とキー式を含む索引列とキー式の集合が、両方の索引で同じである。
  2. INCLUDE 列を含む索引キー列とキー式の順序が、両方の索引で同じである。
  3. 新しい索引のキー列とキー式が同じであるか、または既存の索引内にあるキー列とキー式のスーパーセットである。
  4. 列とキー式の順序付け属性が、両方の索引で同じである。
  5. 既存の索引がユニークである。
  6. 両方の索引が非ユニークである。
  これらの要因の以下の組み合わせにより、考慮対象の 2 つの索引がいつ重複しているかを判別する規則が形成されます。

  • 1 + 2 + 4 + 5
  • 1 + 2 + 4 + 6
  • 1 + 2 + 3 + 5
  例外:

  • 比較している索引の一方がパーティション化されていて、もう一方がパーティション化されていない場合、索引名が異なると、たとえその他の索引一致条件を満たしているとしても、それらの索引は重複しているとは見なされません。
  • XML データについての索引の場合、索引記述は、たとえ索引にされる XML 列、XML パターン、およびオプションも含めたデータ・タイプが同一であっても、索引名が異なっていれば重複しているとはみなされません。
• システム保守 MQT 上のユニーク索引は、サポートされません (SQLSTATE 42809)。
• COLLECT STATISTICS オプションは、 ニックネームが指定される場合にはサポートされません (SQLSTATE 42601)。
• 式ベースのキーがある索引の、パーティション・データベース環境での作成は、カタログ・データベース・パーティションからのみサポートされます (SQLSTATE 42997)。

注

• 索引作成中の同時読み取り/書き込みアクセス、およびデフォルトの索引作成動作は、非パーティション表上の索引、非パーティション索引、パーティション索引において、それぞれ次のように異なります。
  • 非パーティション索引では、索引を作成している間に、表への同時読み取り/書き込みアクセスが許可されます。ただし EXTEND USING 節が指定されている場合を除きます。 索引が作成されると、索引の作成時に表に加えられた変更は、新しい索引に送られ適用されます。 表への書き込みアクセスは、 新しい索引が使用できるようになってから、索引の作成が完了するまでの短時間ブロックされます。
  • パーティション索引では、索引を作成している間に、表への同時読み取り/書き込みアクセスが許可されます。ただし EXTEND USING 節が指定されている場合を除きます。 索引パーティションが作成されると、その索引パーティションの作成時にパーティションに加えられた変更は、新しい索引パーティションに送られ適用されます。 データ・パーティションへの書き込みアクセスは、残りのデータ・パーティションで索引作成が完了するまでブロックされます。 最後のデータ・パーティションの索引パーティションが作成され、トランザクションがコミットされると、すべてのデータ・パーティションで読み書きできるようになります。

  このデフォルトの動作を回避するには、LOCK TABLE ステートメントを使用して、 CREATE INDEX ステートメントが発行される前に表を明示的にロックします。 (表は SHARE か EXCLUSIVE モードのいずれかでロックできます。 読み取りアクセスが許可されているかどうかによります。)

• 指定した表に既にデータが含まれる場合、CREATE INDEX はそのデータの索引項目を作成します。 表にまだデータが含まれていない場合、CREATE INDEX は索引記述を作成します (索引項目は、データが表に挿入される時点で作成されます)。
• 索引が作成され、データが表にロードされた時点で、 RUNSTATS コマンドを実行することをお勧めします。 RUNSTATS コマンドは、データベース表、列、 および索引について収集された統計値を更新します。 これらの統計値は、表への最適アクセス・パスを判別するために使用されます。 RUNSTATS コマンドを実行することによって、 データベース・マネージャーが新しい索引の特性を判別することができます。 CREATE INDEX ステートメントが発行される前にデータをロードする場合には、 CREATE INDEX ステートメントの COLLECT STATISTICS オプションを、 RUNSTATS コマンドの代わりに使用することをお勧めします。
• 索引の作成時に統計を収集する場合は、得られる統計に不整合が生じる可能性があります。表とその表の既存の索引に関する統計を最後に収集した後で表が変更されている場合は、続いて RUNSTATS コマンドを実行して、表とその表のすべての索引にわたって整合性の取れた一式の統計が得られるようにする必要があります。
• まだ存在していないスキーマ名を用いて索引を作成すると、 ステートメントの許可 ID に IMPLICIT_SCHEMA 権限がある場合に限り、 そのスキーマが暗黙に作成されます。 スキーマの所有者は SYSIBM になります。スキーマに対する CREATEIN 特権が PUBLIC に付与されます。
• オプティマイザーは、実際の索引を作成する前に、 複数の索引を推奨することがあります。
• 索引のあるデータ・ソース表に SPECIFICATION ONLY 指定の索引を定義している場合、 その索引名と SPECIFICATION ONLY 指定の索引の名前は一致していなくても構いません。
• Explain 機能、設計アドバイザー、または Data Server Manager の EXPLAIN オプションを使用して、実際の索引を作成する前に索引を推奨することができます。 しかし、これらの方法のいずれも、式ベースのキーが含まれた索引を推奨しません。
• 索引統計の収集: 索引統計の収集方法を変更するために、UNSAMPLED DETAILED オプションを使用できます。 ただしこれは、DETAILED では正確な統計が生成されないことが明らかである場合にのみ、使用してください。
• 生成されるオブジェクト: 索引が式ベースのキーで作成された場合、システム生成統計ビューとシステム生成のパッケージも作成され、この索引と関連付けられます。
• 代替構文: 以下の構文は許容されますが、無視されます。
  • CLOSE
  • DEFINE
  • FREEPAGE
  • GBPCACHE
  • PIECESIZE
  • TYPE 2
  • using-block
  以下の構文はデフォルトの振る舞いとして受け入れられます。

  • COPY NO
  • DEFER NO

例

• 例 1: PROJECT 表に対して UNIQUE_NAM という名前の索引を作成します。 この索引の目的は、 プロジェクト名 (PROJNAME) の値が同じ 2 つの項目が表に作成されないようにすることです。 索引項目は昇順に並べます。

     CREATE UNIQUE INDEX UNIQUE_NAM
        ON PROJECT(PROJNAME)

• 例 2: EMPLOYEE 表に対して JOB_BY_DPT という名前の索引を作成します。 索引項目は、各部門 (WORKDEPT) の中ではジョブ名 (JOB) 順に昇順で並べます。

     CREATE INDEX JOB_BY_DPT
        ON EMPLOYEE (WORKDEPT, JOB)

• 例 3: ニックネーム EMPLOYEE は、CURRENT_EMP というデータ・ソース表を参照します。 このニックネームを作成した後、索引が CURRENT_EMP で定義されます。 索引キー用に選んだ列は WORKDEBT と JOB です。 この索引を記述する SPECIFICATION ONLY 指定の索引を作成します。 この指定を参照することにより、オプティマイザーは、 索引が存在することと索引に含まれるキーを知ることになります。 この情報を利用して、オプティマイザーは、 表をアクセスするときの方法を改善することができます。

     CREATE UNIQUE INDEX JOB_BY_DEPT
       ON EMPLOYEE (WORKDEPT, JOB)
       SPECIFICATION ONLY        

• 例 4: 構造化タイプ列の位置に、拡張索引タイプ SPATIAL_INDEX を作成します。 索引拡張 GRID_EXTENSION の記述が SPATIAL_INDEX を保守するのに使用されます。 リテラルが GRID_EXTENSION に指定されて、索引格子サイズを作成します。

     CREATE INDEX SPATIAL_INDEX ON CUSTOMER (LOCATION)
       EXTEND USING (GRID_EXTENSION (x'000100100010001000400010'))

• 例 5: TAB1 という名前の表に IDX1 という名前の索引を作成し、 索引 IDX1 の基本索引統計を収集します。

     CREATE INDEX IDX1 ON TAB1 (col1) COLLECT STATISTICS

• 例 6: TAB1 という名前の表に IDX2 という名前の索引を作成し、 索引 IDX2 の詳細な索引統計を収集します。

     CREATE INDEX IDX2 ON TAB1 (col2) COLLECT DETAILED STATISTICS

• 例 7: TAB1 という名前の表に IDX3 という名前の索引を作成し、 サンプリングを使用して索引 IDX3 の詳細な索引統計を収集します。

     CREATE INDEX IDX3 ON TAB1 (col3) COLLECT SAMPLED DETAILED STATISTICS

• 例 8: 表スペース IDX_TBSP 内の MYNUMBERDATA というパーティション表に A_IDX というユニーク索引を作成します。

     CREATE UNIQUE INDEX A_IDX ON MYNUMBERDATA (A) IN IDX_TBSP

• 例 9: 表スペース IDX_TBSP 内の MYNUMBERDATA というパーティション表に B_IDX という非ユニーク索引を作成します。

     CREATE INDEX B_IDX ON MYNUMBERDATA (B)
       NOT PARTITIONED IN IDX_TBSP

• 例 10: COMPANYDOCS という XML 列を含む、COMPANYINFO という表に、XML データの索引 を作成します。 XML 列 COMPANYDOCS には、以下のような数多くの XML 文書が含まれます。

  <company name="Company1">
    <emp id="31201" salary="60000" gender="Female">
      <name>
        <first>Laura</first>
        <last>Brown</last>
      </name>
      <dept id="M25">
        Finance
      </dept>
    </emp>
  </company>

  COMPANYINFO 表のユーザーは、頻繁に、従業員 ID を使用して従業員情報を検索する必要があります。 以下のような索引を作成すると、そうした検索がより効率的になる可能性があります。

     CREATE INDEX EMPINDEX ON COMPANYINFO(COMPANYDOCS)
       GENERATE KEY USING XMLPATTERN '/company/emp/@id'
         AS SQL DOUBLE

• 例 11: 以下の索引は、論理的には前の例で作成したものと同等ですが、短縮していない構文を使用している点が異なります。

     CREATE INDEX EMPINDEX ON COMPANYINFO(COMPANYDOCS)
       GENERATE KEY USING XMLPATTERN '/child::company/child::emp/attribute::id'
         AS SQL DOUBLE

• 例 12: 本のタイトルだけを VARCHAR(100) として索引にし、DOC という列に索引を作成します。 本のタイトルは、どれも他のすべての本と異なる固有なものなので、索引もユニークでなければなりません。

     CREATE UNIQUE INDEX MYDOCSIDX ON MYDOCS(DOC)
       GENERATE KEY USING XMLPATTERN '/book/title'
         AS SQL VARCHAR(100)

• 例 13: 章番号を DOUBLE として索引にし、DOC という列に索引を作成します。 この例には、名前空間宣言が含まれます。

     CREATE INDEX MYDOCSIDX ON MYDOCS(DOC)
       GENERATE KEY USING XMLPATTERN
         'declare namespace b="http://www.example.com/book/";
           declare namespace c="http://acme.org/chapters";
             /b:book/c:chapter/@number'
         AS SQL DOUBLE

• 例 14: 表 PROJECT に IDXPROJEST という名前のユニーク索引を作成し、列 PRSTAFF を組み込んで見積平均スタッフ配置情報の索引のみのアクセスを可能にします。

     CREATE UNIQUE INDEX IDXPROJEST ON PROJECT (PROJNO) INCLUDE (PRSTAFF)

• 例 15: USER_ID という名前が付いた列にユニーク索引を作成し、その索引から NULL キーを除外します。

     CREATE UNIQUE INDEX IDXUSERID ON CUSTOMER (USER_ID) EXCLUDE NULL KEYS

• 例 16: 式ベースのキーを持つ索引を、大文字の従業員の名前と ID を使用して作成します。

     CREATE INDEX EMP_UPPERNAME ON EMPLOYEE (UPPER(NAME), ID)