概要
| この記事の結論 Accessのインデックスは、検索や並べ替えで目的のレコードを見つけやすくするための索引です。よく検索する列や結合に使う列で効果を期待できますが、追加・更新時には索引の更新も発生します。すべての列に付ければ速くなるわけではありません。主キーには自動で索引が作られるため、重複した設定を避け、実際の処理時間で効果を確認します。 |
この記事でわかること
- 検索列・結合列から検討
- 更新処理には負担も発生
- 複合索引は列順が重要
- 同じ条件で変更前後を測定
この記事の主な内容
- インデックスの仕組みと役割
- 設定する列と設定を控える列
- 単一フィールドにインデックスを設定する
- 複合インデックスと重複禁止の使い分け
- インデックスを付けても遅い原因
- 効果測定と運用時の見直し方
- よくある質問
想定読了時間：約6分～8分
1 インデックスの仕組みと役割
インデックスは、本の索引のように目的の値へたどり着きやすくする情報です。テーブル全体を順に調べる負担を減らせる場合があります。ただし、フォームに表示される並び順を固定する機能ではありません。表示順を保証したい場合は、クエリの並べ替えなどで指定します。
主キーを設定すると、その主キーに対するインデックスが自動的に作られます。主キーと同じ列へ同じ目的の索引を重ねる前に、既存の設定を確認しましょう。性能改善では、索引の数を増やすことより、どの処理を速くしたいのかを明確にすることが出発点です。
参考：Microsoft インデックスを作成してパフォーマンスを向上する ／
参考：Microsoft テーブルの主キーを追加または変更する
2 設定する列と設定を控える列
最初に候補にするのは、検索条件、テーブル間の結合、並べ替えでよく使用する列です。例えば顧客コードで受注を探す業務なら、検索・結合に使う顧客コードの設定を確認します。ほとんど使わない備考欄へ機械的に付ける必要はありません。
| 列の使われ方 | 検討の方向 |
|---|---|
| IDやコードで頻繁に検索 | 索引の有無を確認 |
| 他のテーブルと結合 | 結合列と型の対応を確認 |
| 同じ値が大部分を占める | 効果が小さい場合がある |
| 大量に追加更新する | 書込負荷も測る |
索引がある列を追加・変更すると、索引側にも処理が発生します。検索だけ速くなっても、毎朝の大量取り込みが長くなる場合があります。利用頻度と処理の優先順位を整理し、全体の業務時間が短くなるかで判断してください。
参考：Microsoft インデックスを作成してパフォーマンスを向上する
3 単一フィールドにインデックスを設定する
単一列の索引は、テーブルのデザインビューで設定できます。既存の業務テーブルでは、バックアップを取り、利用者が操作していない時間帯に作業します。リンクテーブルの場合は、通常、実データを持つ側のテーブルで設計を確認します。
1. 対象テーブルを［デザインビュー］で開きます。
2. 索引を設定したいフィールドを選びます。
3. 下部のフィールドプロパティにある［インデックス］を確認します。
4. 用途に応じて［はい（重複あり）］または［はい（重複なし）］を選び、保存します。
5. 検索時間と登録・更新時間を、変更前と同じ条件で比べます。
顧客IDを持つ受注テーブルのように同じ顧客が何度も登場する列では、重複を許す設定が必要です。［重複なし］を選ぶと、同じ顧客の2件目の受注が登録できなくなる設計になり得ます。速度と業務上の一意性は別の判断です。
4 複合インデックスと重複禁止の使い分け
複数列をまとめた索引は、テーブルデザインの［インデックス］ウィンドウで作成します。最初の行に索引名と1つ目のフィールドを指定し、続く行の索引名を空欄にして2つ目以降のフィールドを並べると、1つの複合インデックスとして扱われます。
「受注ID＋行番号」を一意にする場合、同じ行番号が別の受注に存在することは許可し、同じ受注内の同じ行番号だけを防げます。一方、行番号だけに［重複なし］を設定すると全受注を通じた重複禁止となり、意味が変わります。
複合索引の列順は検索条件と合わせて考えます。「顧客ID＋受注日」の索引なら、顧客を指定して期間を絞る処理が検討対象になります。受注日だけの検索に同じ効果があると決めつけず、実際のクエリで確かめます。
複数テーブルや複数端末への影響が分からない場合は、変更目的と現状の構成を整理してお気軽にご相談ください。
5 インデックスを付けても遅い原因
索引があっても、列を関数で加工した条件やデータ型の異なる列同士の比較では、期待どおり利用されない場合があります。また、必要な列を絞らず大量のデータを画面へ読み込んでいるなら、索引だけでは通信や表示の負担は消えません。
- 検索列に不要な型変換や文字列加工をかけていないか。
- 結合する両側の列の型が適切に揃っているか。
- 「含む」検索や前方にワイルドカードを置く検索を多用していないか。
- ネットワーク越しに全件取得してから絞り込んでいないか。
例えば日付を文字列へ変換して月を比較するより、日付の開始以上・翌月開始未満という範囲条件の方が扱いやすい場合があります。ただし書き換え時は、時刻を含む値や境界日の扱いまで検証してください。性能と抽出結果の正しさを同時に確認します。
6 効果測定と運用時の見直し方
測定する処理は、利用者が待っている検索や帳票などから選びます。同じデータ件数、同じ抽出条件、同じ端末・接続先で変更前後を測り、1回だけの偶然の差で判断しないようにします。最初の起動と再実行ではキャッシュの影響で時間が違うこともあります。
- 検索結果の件数と内容が変わっていないか確認する。
- 検索・帳票だけでなく、登録や一括取り込みの時間も確認する。
- 追加した索引名と列順、変更前の設定を記録する。
- 効果が乏しい索引は、依存する一意性の制約を確認してから見直す。
主キーや重複禁止の索引は、性能以外にデータ品質を守る役割があります。遅さを直すために制約まで一括削除してはいけません。索引、クエリ、画面、ネットワークのどこに時間がかかるかを分けて改善します。
よくある質問（FAQ)
いいえ。更新時の負担やファイル容量も増えるため、実際の検索・結合で必要な列を選びます。
主キーは行を一意に識別する役割です。インデックス（索引）は検索を助ける仕組みで、主キーには自動で索引が作られます。
速さだけで選ばずに、業務上同じ値を許可するかで決め、実際の性能を検証します。
固定されません。表示順を必要とするクエリでは並べ替え条件を指定します。
Accessクエリ・検索性能の改善が必要な場合
この記事の手順を作業用コピーで確認しても解決しない場合や、業務への影響が大きく自社だけで判断しにくい場合は、お気軽にご相談ください。Accessの現在の構成、発生している症状、変更したい内容をもとに、調査・改修の範囲を整理します。
ご相談時は、Accessの製品名・Build・bit数、エラーの内容、対象ファイルの構成、直前に変えた設定を分かる範囲でお知らせください。機密データやパスワードは公開フォーム等へそのまま記載しないでください。