SQL データ操作の基礎 (中級) 6

第 10 章「SQL の基礎」では、SQL の予備的な概要を説明します。 SELECT ステートメントを使用してクエリを実行する方法と、独自のテーブルを作成する方法を学習しました。この章では、SQL についての知識を深めます。クエリを高速化するためにインデックスを作成する方法を学びます。また、より多くの SQL ステートメントと関数を使用してテーブル内のデータを操作する方法も学習します。

インデックス作成

この本の中で特定の文を見つけたいとします。ページごとに検索することもできますが、非常に時間がかかります。また、この本の索引を使用すると、探しているトピックをすぐに見つけることができます。

表の索引は、本の後ろに付いている索引とよく似ています。これにより、クエリの速度が大幅に向上します。大きなテーブルの場合、インデックスを追加すると、通常は完了までに数時間かかるクエリがわずか数分で完了します。したがって、頻繁なクエリを必要とするテーブルにインデックスを追加する理由はありません。

注:

メモリ容量またはハードディスク容量が不十分な場合は、テーブルにインデックスを追加したくない場合があります。インデックスを含むデータベースの場合、SQL サーバーにはかなりの追加スペースが必要です。たとえば、クラスター化インデックスを作成するには、約 1.2 倍のデータ サイズが必要です。データベース内でテーブル インデックスが占める領域の量を確認するには、システム ストアド プロシージャ sp_spaceused を使用し、インデックス付けされるテーブルの名前としてオブジェクト名を指定します。

クラスター化索引と非クラスター化索引

この本の索引から文のページ番号を見つけたと仮定します。ページ番号がわかると、正しいページ番号が見つかるまで本を読み進めることになるでしょう。ランダムに検索すると、最終的に正しいページ番号に到達することができます。ただし、ページ番号を見つけるにはもっと効率的な方法があります。

まず、本を半分くらいめくってください。探しているページ番号が半分のページ番号より小さい場合は、本を4分の3までめくってください。方法。 。こうすることで、正しいページ番号に近いページが見つかるまで、本をさらに小さな部分に分割し続けることができます。これはページを見つけるのに非常に効果的な方法です。

SQL サーバーのテーブル インデックスも同様に機能します。テーブル インデックスは、ツリー構造を形成する一連のページで構成されます。ルート ページは、他の 2 つのページを指すことにより、テーブルのレコードを論理的に 2 つの部分に分割します。ルート ページが指す 2 つのページは、レコードをより小さな部分に分割します。各ページは、リーフレベルのページに到達するまで、レコードをより小さなパーティションに分割します。

インデックスには、クラスター化インデックスと非クラスター化インデックスの 2 種類があります。クラスター化インデックスでは、インデックス ツリーのリーフ レベルのページに実際のデータが含まれます。レコードのインデックス順序は物理的な順序と同じです。ノンクラスタード インデックスでは、リーフ レベルのページがテーブル内のレコードを指します。レコードの物理的な順序は、必ずしも論理的な順序に関連しているわけではありません。

クラスター化インデックスはディレクトリ テーブルに非常によく似ており、ディレクトリ テーブルの順序は実際のページ番号の順序と一致します。非クラスター化インデックスは、書籍の標準的なインデックス テーブルに似ています。通常、インデックス テーブル内の順序は実際のページ番号の順序と一致しません。書籍には複数の索引がある場合があります。たとえば、件名インデックスと作成者インデックスの両方が含まれる場合があります。同様に、テーブルには複数の非クラスター化インデックスを含めることができます。

通常はクラスター化インデックスを使用しますが、両方のタイプのインデックスの長所と短所を理解しておく必要があります。

テーブル内のレコードは 1 つの物理的な順序でのみ保存できるため、各テーブルには 1 つのクラスター化インデックスのみを含めることができます。通常、識別フィールドに基づいてテーブルにクラスター化インデックスを作成する必要があります。ただし、文字フィールド、数値フィールド、日時フィールドなど、他のタイプのフィールドに対してクラスター化インデックスを作成することもできます。

クラスター化インデックスを使用したテーブルからのデータの取得は、非クラスター化インデックスを使用したテーブルよりも高速です。特定の範囲内のデータを取得する必要がある場合は、非クラスター化インデックスよりもクラスター化インデックスを使用する方が適しています。たとえば、テーブルを使用してサイトの訪問者のアクティビティを記録するとします。一定期間内のログイン情報を取得したい場合は、このテーブルの DATETIME 型フィールドにクラスター化インデックスを作成する必要があります。

クラスター化インデックスの主な制限は、テーブルごとにクラスター化インデックスを 1 つだけ作成できることです。ただし、テーブルには複数の非クラスター化インデックスを含めることができます。実際、テーブルごとに最大 249 個の非クラスター化インデックスを作成できます。テーブルにクラスター化インデックスと非クラスター化インデックスを同時に作成することもできます。

サイトのアクティビティ ログから日付だけでなくユーザー名にも基づいてデータを取得したいとします。この場合、クラスタードインデックスとノンクラスタードインデックスを同時に作成すると効果的です。 datetime フィールドにクラスター化インデックスを作成し、ユーザー名フィールドに非クラスター化インデックスを作成できます。さらに多くのインデックス作成方法が必要な場合は、非クラスター化インデックスをさらに追加できます。

非クラスター化インデックスには、大量のハード ディスク領域とメモリが必要です。さらに、非クラスター化インデックスを使用すると、 また、テーブルへのデータの挿入および更新の速度も低下します。非クラスター化インデックスを持つテーブルのデータを変更する場合は、必ずインデックスも更新する必要があります。したがって、テーブルに非クラスター化インデックスを作成する場合は、慎重に検討する必要があります。テーブルでデータを頻繁に更新する必要があることが予想される場合は、そのテーブルに非クラスター化インデックスを作成しすぎないでください。さらに、ハード ディスクとメモリのスペースが限られている場合は、使用する非クラスター化インデックスの数も制限する必要があります。

インデックス プロパティ

これら 2 種類のインデックスには 2 つの重要なプロパティがあります。どちらのタイプも同時に複数のフィールドにインデックスを付けることができます (複合インデックス)。両方のタイプのインデックスを一意のインデックスとして指定できます。

複数のフィールドに対して複合インデックスを作成したり、複合クラスター化インデックスを作成したりすることもできます。 Web サイトへの訪問者の姓名を記録するテーブルがあるとします。完全な名前に基づいてテーブルからデータを取得する場合は、姓フィールドと名前フィールドの両方にインデックスを作成する必要があります。これは、2 つのフィールドに個別のインデックスを作成することとは異なります。複数のフィールドを同時にクエリする場合は、複数のフィールドにインデックスを作成する必要があります。各フィールドを個別にクエリする場合は、フィールドごとに独立したインデックスを作成する必要があります。

どちらのタイプのインデックスも一意のインデックスとして指定できます。フィールドに一意のインデックスが付いている場合、フィールドに重複した値を入力することはできません。識別フィールドは自動的に一意の値フィールドになりますが、他の種類のフィールドに一意のインデックスを作成することもできます。テーブルを使用してサイトのユーザー パスワードを保存するとします。2 人のユーザーが同じパスワードを使用することは絶対に望ましくありません。フィールドを強制的に一意の値フィールドにすることで、この問題の発生を防ぐことができます。

上記は SQL データ操作の基礎 (中級) 6 の内容です。その他の関連記事については、PHP 中国語 Web サイト (www.php.cn) に注目してください。