最近、SQLデータベースを使用する最初の本格的なアプリケーションの開発を開始し、phpMyAdminを使用してテーブルを設定しています。さまざまな列に指定できるオプションの「機能」がいくつかありますが、それらが何をするのか完全にはわかりません。
PKの目的と使用方法は知っていますが、それに関する私の質問は、なぜPKが必要なのかということだと思います。列を単に「一意」に設定するのとは、できるという事実以外はどう違うのでしょうか。 PKは1つだけですか?この値がレコードを一意に識別することをプログラマーに知らせるだけですか?それともいくつかの特別な特性がありますか?
「インデックス」が何をするのかわかりません。実際、「インデックス」が使用されているのを目にしたのは、(1)主キーにインデックスが付けられているように見えること、(2)インデックスが何らかの形でパフォーマンスに関連していることだけです。 ;インデックス付きの列が必要ですが、多すぎないようにします。インデックスを作成する列をどのように決定し、正確に何をするのでしょうか。
編集: 1つのインデックス列でORDERBYを実行する必要がありますか?
どうもありがとう、
マラ
主キーは通常、レコードの数値「id」を作成するために使用され、このid列は自動的にインクリメントされます。
たとえば、books
フィールドを持つid
テーブルがある場合、id
は主キーであり、auto_increment
にも設定されます(「追加」の下) phpmyadmin)で、最初に本をテーブルに追加すると、そのIDは1 'になります。次の本のIDは自動的に「2」になります。通常、レコードを簡単に識別および検索できるように、すべてのテーブルに少なくとも1つの主キーが必要です。
インデックスは、テーブルから特定の情報を定期的に取得する必要がある場合に使用されます。たとえば、users
テーブルがあり、email
列に頻繁にアクセスする必要がある場合は、メールにインデックスを追加できます。これにより、メールにアクセスするクエリが発生します。より速くなります。
ただし、不要なインデックスを追加することには欠点もあるため、他の列よりも実際にアクセスする必要がある列にのみこれを追加してください。たとえば、UPDATE
、DELETE
、およびINSERT
クエリは、インデックスが多いほど、MySQLがインデックス付きの各列に追加情報を格納する必要があるため、少し遅くなります。詳細については、 このページ を参照してください。
編集:はい、ORDER BY
で頻繁に使用する必要がある列には、WHERE
で使用されるものと同様にインデックスが必要です。
主キーは基本的に、そのテーブルの行の「公式」IDとして機能する一意のインデックス付き列です。最も重要なことは、一般的に外部キーの関係に使用されます。つまり、別のテーブルが最初の行を参照している場合、その行の主キーのコピーが含まれます。
複合主キー、つまり複数の列で構成される主キーを持つことが可能であることに注意してください。
インデックスはルックアップ時間を改善します。これらは通常ツリーベースであるため、インデックスを介して特定の行を検索するには、テーブル全体をスキャンするのではなく、O(log(n))時間がかかります。
一般に、WHERE
、ORDER BY
、または(特に)JOIN
句で頻繁に使用される大きなテーブルの列には、インデックスが必要です。インデックスはINSERT
、UPDATE
、またはDELETE
ごとに更新する必要があるため、これらの操作の速度が低下します。書き込みが少なく、読み取りが多い場合は、ヒアリングのコンテンツにインデックスを付けます。多くの列にインデックスを必要とする書き込みとクエリの両方がある場合、大きな問題が発生します。
主キーと一意キーの違いは、例を通して最もよく説明されています。
ユーザーの表があります。
USER_ID number
NAME varchar(30)
EMAIL varchar(50)
そのテーブルでは、USER_IDが主キーです。名前は一意ではありません。世界中にジョン・スミスとムハメッド・カーンがたくさんいます。 EMAILは必然的に一意です。そうでないと、世界中の電子メールシステムが機能しません。そのため、EMAILに独自の制約を課しました。
では、なぜ別の主キーが必要なのですか? 3つの理由:
リレーショナルモデルでは、テーブル内に存在し、一意であることが保証されている列または列のセットを、テーブルの候補キーと呼ぶことができます。 「現在」は「NOTNULL」を意味します。データベース設計では、候補キーの1つを主キーとして指定し、主キーへの参照を使用して行全体、または行が説明する主題項目を参照するのが一般的です。
SQLでは、PRIMARYKEY制約は各主キー列のNOTNULL制約になり、すべての主キー列のUNIQUE制約が一緒になります。実際には、多くの主キーは単一の列であることがわかります。
ほとんどのDBMS製品では、PRIMARY KEY制約により、主キー列にインデックスが自動的に作成されます。これにより、主キーに新しいエントリが作成されたときにシステムチェックアクティビティが高速化され、新しい値が既存の値と重複しないことが確認されます。また、主キーの値に基づいてルックアップを高速化し、主キーとそれを参照する外部キーを結合します。どの程度の速度向上が発生するかは、クエリオプティマイザがどのように機能するかによって異なります。
もともと、リレーショナルデータベースの設計者は、与えられたとおりにデータ内の自然キーを探していました。近年、IDと呼ばれる列、最初の列としての整数、およびすべてのテーブルの主キーを常に作成する傾向があります。 DBMSの自動生成機能は、このキーが一意になるようにするために使用されます。この傾向は、「オスロ設計基準」に記載されています。これは必ずしもリレーショナル設計ではありませんが、それに従う人々の差し迫ったニーズに応えます。私はこの方法をお勧めしませんが、それが一般的な方法であることを認識しています。
インデックスは、インデックスが作成されたテーブルの列の説明に基づいて、テーブルのいくつかの行にすばやくアクセスできるようにするデータ構造です。インデックスは、インデックスキーと呼ばれる特定のテーブル列のコピーで構成され、テーブル行へのポインタが点在しています。ポインタは通常、DBMSユーザーには表示されません。インデックスは、クエリオプティマイザと連携して機能します。ユーザーはSQLでどのデータを探しているかを指定し、オプティマイザーは、探しているものをそれを見つけるための状態に変換するためのインデックス戦略やその他の戦略を考え出します。ソートやハッシュなど、インデックスを高速ルックアップやその他の特定の用途に使用できるようにする、ある種の編成原則があります。データベースビルダーがインデックスを作成するか、主キーを宣言すると、これはすべてDBMSの内部にあります。
主キーとは関係のないインデックスを作成できます。主キーはインデックスなしで存在できますが、これは一般的に非常に悪い考えです。