CREATE INDEX

ページサイズ（バイト数）	キーセグメントの最大数（ファイルバージョン別）
ページサイズ（バイト数）	8.x 以前	9.0	9.5	13.0
512	8	8	切り上げ2	切り上げ2
1,024	23	23	97	切り上げ2
1,536	24	24	切り上げ2	切り上げ2
2,048	54	54	97	切り上げ2
2,560	54	54	切り上げ2	切り上げ2
3,072	54	54	切り上げ2	切り上げ2
3,584	54	54	切り上げ2	切り上げ2
4,096	119	119	2043	1833
8,192	N/A1	119	4203	3783
16,384	N/A1	N/A1	4203	3783
1 N/A は「適用外」を意味します。 2 「切り上げ」は、ページサイズを、ファイルバージョンでサポートされる次のサイズへ切り上げることを意味します。たとえば、512 は 1024 に切り上げられ、2560 は 4096 に切り上げるということです。 3 9.5 以降の形式のファイルでは 119 以上のセグメントを指定できますが、インデックスの数は 119 に制限されます。

ヌル値を許可する列には考慮も必要です。たとえば、ページサイズが 4096 バイトのデータファイルでは、1 ファイル当たりのインデックスセグメント数は 119 に制限されます。真のヌルがサポートされるインデックス付きのヌル値を許可する列には 2 つのセグメントから成るインデックスが必要なため、1 つのテーブルではインデックス付きのヌル値を許可する列（Btrieve ファイルでは、インデックス付きでヌル値を許可する真のヌルフィールド）は 59 個までしか持てません。ページサイズが小さくなると、この制限も小さくなります。

ファイルバージョンを 7.x 以降として作成され、TRUENULLCREATE がオンに設定されているファイルは、真のヌルをサポートします。それより前のファイル形式で作成されたファイル、あるいは Pervasive.SQL 7 を使用するか TRUENULLCREATE をオフに設定して作成されたファイルは、真のヌルをサポートせず、この制限を受けません。

UNIQUE

UNIQUE インデックスキーは、特定の行に対してインデックスで定義された列の組み合わせがファイル内で重複しないことを保証します。これは、複数セグメントのインデックスの場合には、個々の列が重複しないことを保証しませんし、また要求もしません。

メモ：次のデータ型以外のすべてのデータ型にインデックスを設定できます。
BIT
BLOB
CLOB
LONGVARBINARY
LONGVARCHAR
NLONGVARCHAR

『Status Codes and Messages』のステータスコード「6008：セグメントが多すぎます。」も参照してください。

PARTIAL

CREATE INDEX ステートメントで PARTIAL キーワードを使用すると、長さの合計が 255 バイトを超える 1 つの列または列のグループでインデックスを作成できます。

部分インデックスは、大きな列のプレフィックスを使用して作成されるか、あるいは小さな列を複数組み合わせて作成されるため、大きな列のプレフィックスを用いた検索の方がより速く実行できます。したがって、WHERE 句で 'WHERE column_name LIKE 'prefix%' のような制限を使用しているクエリは、インデックスを何も使用しない場合とは対照的に、部分インデックスを使用することによって実行が速くなります。

CREATE INDEX ステートメントに PARTIAL キーワードを含めた場合、インデックス列の幅とオーバーヘッドが 255 バイト以上でなければ、PARTIAL キーワードは無視され、代わりに標準のインデックスが作成されます。

メモ：幅は列の実際のサイズを指し、オーバーヘッドはヌルインジケーターや文字列の長さなどを指します。

PARTIAL の制限事項

PARTIAL を使用する際には次の制限が適用されます。

•

部分インデックスは、データ型が CHAR または VARCHAR の列にしか追加できません。

•

部分インデックス列は、必ずインデックス定義内の最後のセグメントであるか、あるいはインデックス定義内の唯一のセグメントである必要があります。

部分インデックス列がインデックス内の唯一のセグメントである場合、列のサイズは最大 8,000 バイトにすることができますが、ユーザーデータのインデックスセグメントのサイズは 255 バイトになります。

•

エンジンは、厳密な等式を含んでいるクエリや、部分列にかかわる ORDER BY、GROUP BY、JOIN などの照合操作を実行している場合には、部分インデックスを使用しません。

•

部分インデックスは、WHERE 句の次のような形式の制限と照合する場合にのみ使用されます。

WHERE col = 'literal'

WHERE col LIKE 'literal%'

WHERE col = ?

WHERE col LIKE ?

ここで、literal、つまり実引数値にはどのような長さの値も指定できます。部分インデックス列でインデックス処理されたバイト数より短くても長くてもかまいません。LIKE 句の形式が 'prefix%' でない場合、部分インデックスは使用されません。

WHERE 句が前述の制限事項に適合する場合は、実行プランを立てる際に部分インデックスが使用されます。

メモ：ALTER TABLE を使用して部分インデックス列の長さを変更したとき、変更後の長さが 255 バイトのインデックスに収まるようになった場合、あるいは 255 バイトを超えてしまった場合には、ユーザーの責任の下、ユーザーの要求に従って、そのインデックスの削除および再作成を行ってください。

例

このセクションでは、CREATE PARTIAL INDEX のいくつかの例を示します。

次の例では、データ型とサイズの指定された PartID、PartName、SerialNo、および Description 列を含む、Part_tbl という名前のテーブルが作成されます。

CREATE TABLE part_tbl (partid INT, partname CHAR(50), serialno VARCHAR(200), description CHAR(300));

次に、Description 列を使って、idx_01 という名前の部分インデックスを作成します。

CREATE PARTIAL INDEX idx_01 on part_tbl (description);

インデックスで使用される Description 列は 300 バイトありますが、PARTIAL キーワードを使用することにより、先頭の 255 バイト（オーバーヘッドを含む）だけをプレフィックスとしてインデックスで使用できるようになります。

============

次の例では、前の例と同じテーブルに idx_02 という部分インデックスを作成します。代わりに、この例では PartId、SerialNo、および Description 列をまとめてインデックスに使用します。

CREATE PARTIAL INDEX idx_02 on part_tbl (partid, serialno, description);

次の表は、どのようにして大きい列がインデックスに割り当てられるかを理解できるよう、インデックス列の詳細を示しています。

列名	データ型	サイズ	オーバーヘッド	インデックス内のサイズ
PartID	Integer	4		4
SerialNo	Varchar	200	1	201
Description	Char	300		50
インデックスの合計サイズ				255

NOT MODIFIABLE

この属性は、インデックスが変更されないようにします。複数セグメントのインデックスでは、この属性はすべてのセグメントに適用されることに留意してください。このセグメントのいずれかを変更しようとすると、ステータスコード「10：キーフィールドは変更できません。」が返されます。

次の例では、Person テーブルに変更できないセグメントインデックスが作成されます。

CREATE NOT MODIFIABLE INDEX X_Person on Person(ID, Last_Name)

USING

インデックスを作成するときにインデックス番号を制御するには、このキーワードを使用します。インデックス番号を制御することは、リレーショナルエンジンを使ってデータにアクセスする場合だけでなく、MicroKernel エンジンを使って直接データファイルからアクセスする場合にも重要です。

インデックスを作成すると、データファイルと X$Index の両方に指定したインデックス番号が挿入されます。

指定したインデックス番号がどちらかのファイルで既に使用されている場合は、エラーコードが返されます。X$Index の場合はステータスコード「5：レコードのキーフィールドに重複するキー値があります。」、データファイルの場合はステータスコード「6：キー番号パラメーターが不正です。」が返されます。

CREATE INDEX "citizen-x" USING 3 On Person (citizenship)

IN DICTIONARY

このキーワードは、基となる物理データは変更しないままで DDF に変更を加えたいことを、データベースエンジンに通知します。この機能を使用すると、対応するデータファイルと同期していないテーブルの辞書定義を訂正したり、辞書に定義を作成して既存のデータファイルと合致させたりすることができます。これが必要となるのは、ほとんどの場合、Btrieve（トランザクショナル）アプリケーション（DDF を使用しない）によってデータファイルが作成され、使用されるときです。その場限りのクエリやレポートでは、リレーショナルエンジンを使用してデータにアクセスする必要があります。

通常、データベースエンジンは DDF とデータファイルの完全な同期を保ちます。IN DICTIONARY ステートメントを指定しないでインデックスを作成すると、データベースエンジンは X$Index とデータファイルに同じインデックス番号を割り当てます。IN DICTIONARY は、インデックスを X$Index にのみ追加できるようにします。

注意： IN DICTIONARY は強力で高度な機能です。これは、システム管理者によってのみ、もしくは絶対的に必要な場合にのみ使用してください。DDF の変更を基となるデータファイルへの変更と並行して行わないと、不正な結果セット、パフォーマンスの問題、予期しない結果などの重大な問題が生じることがあります。

ファントムインデックス、つまり、DDF にのみ存在しデータファイルには存在しないインデックスを作成した場合、IN DICTIONARY を使用しないでそのインデックスを削除しようとすると、ステータスコード「6：キー番号パラメーターが不正です。」が返されることがあります。このエラーは、データベースエンジンがデータファイルからインデックスを削除しようとしても、そのようなインデックスはデータファイルに存在しないために削除できないことから発生します。

インデックスの作成時に、SQL ステートメントで IN DICTIONARY と USING の両方を使用した場合、USING で指定された番号を使用する新しいインデックスは、指定されたインデックス番号のセグメントが SQL 列と合致する場合には、DDF にのみ挿入されます。USING キーワードで指定された番号が SQL 列と合致しないか、またはデータファイルに存在しない場合、SQL エンジンは「Btrieve キー定義がインデックス定義と一致しません」というエラーメッセージを返します。これにより、ファントムインデックスが作成されないようになります。

メモ：IN DICTIONARY キーワードをバウンドデータベースで使うことはできません。

例

このセクションでは、IN DICTIONARY のいくつかの例を示します。

CREATE TABLE t1 IN DICTIONARY (c1 int, c2 int)

CREATE INDEX idx_1 IN DICTIONARY on t1(c1)

DROP INDEX t1.idx_1 IN DICTIONARY

============

次の例では、既存のテーブル T1 を使用します。データファイルには key1 が定義されていますが、現在のところ X$Index には定義されていません。

CREATE INDEX idx_1 USING 1 IN DICTIONARY on T1 (C2)