4D Japan Knowledge Base

インデックスについて教えて下さい

インデックスは、並び替えおよびクエリのパフォーマンスを向上する役目を持っています。また、統計関数はインデックスが利用可能な時、インデックスを用いて計算します。

インデックスキーの最大数

テーブル毎のレコード数の上限10億に対して、インデックスキーの上限が1280億です。テキストフィールドに対してもインデックスがつけられるようになったためです。たとえば、レコード毎平均128語以内の単語数であれば、完全なインデックスを生成できます。

複合インデックス（姓+名、名+姓、姓、名...）という形でレコード数以上のインデックスをつけることができます。

注意：4D v2004では、レコード数の上限と同数、つまり1600万のインデックスキーがテーブル毎の上限になります。

インデックスの利点

インデックスがあれば、データベースはレコードをひとつずつ読み込まなくても、並び替えやクエリを完了することができます。レコードがデータファイル内で散在している場合でも、良好なパフォーマンスを期待することができます。インデックスは、メモリにキャッシュされるので、繰り返し利用されるレコードには特に効果的です。

インデックスの注意事項

インデックスを管理するためには、余分な領域がディスクに必要です。インデックスは常に最新の状態であることが必須であるため、レコードを変更・追加・削除するたびに更新されなければなりません。

高速モードと従来モード - 4D 2004まで

大量のレコードが存在するテーブルに対してインデックス属性を追加すると、作成の方法を選択するダイアログが表示されます。この設定は、最初にインデックスを作成する方法を指定するものであり、以後の動作にはまったく関係ありません。

従来モードとは、1レコード毎に読み込んでインデックスを構築する方法です。インデックス構築プロセスが1レコードずつ読み込むので構築中も不便は生じません。トランザクションやロックなど、別プロセスがレコードをキープしている状況に遭遇すると、インデックス構築プロセスはそのレコードが解放されるまで永久に待機します。飛ばして後から再試行することはありません。

高速モードとは、テーブルをまるごとロックし、一気にインデックスを構築する方法です。インデックスが作成されるまでそのテーブルのレコードはロックされます。逆にインデックス構築プロセス以外のプロセスがレコードをロックしていれば、エラーとなり、インデックスの作成は失敗します。

いずれも作成の方法に関する設定であり、結果として出来上がるインデックスはまったく同じものです。また運用中のインデックス更新は常に1レコード単位、すなわち従来モードです。

最適化 - 4D 2004まで

最適化オプションも、最初にインデックスを作成する方法を指定するものです。SET INDEXコマンドでも同じプロパティを設定することができ、この設定は、インデックステーブルの内部構造（ページサイズ）に反映されます。

クエリ向きのインデックスとは、最少のページサイズを使用し、隙間なくインデックスを構築するタイプのインデックスです。サイズがコンパクトなため、検索には向いていますが、レコードを更新すれば、インデックスの再配置に多少の手間を要します。

更新向きのインデックスとは、大きめのページサイズを使用し、いくらかの余裕を持ったインデックスのことです。スペースに余裕があるので更新には向いていますが、サイズが大きい分、ディスクからメモリへの読み込みには余分の時間を要します。

いずれにしても、こうした細かい設定による明白な違いが現れるのは、レコード数が数百万を超えてからです。なお、このパラメータは4D v11 SQLで廃止されました。より効果的な新しいインデックスのメカニズムが実装されたからです。

SET INDEX - 4D 2004

インデックスを破棄、または再作成するための古いコマンドです。オプションでページサイズの大きさをパーセント値で指定することができます。

CREATE INDEX, DELETE INDEX - 4D v11以降

プ（Cluster BTree Index, Default Index Type, Keywords Index, Standard BTree Index）を指定することができます。