1.データベースインデックスとは
ライブラリ内のカテゴリクエリカードと同様のデータベースインデックスは、データベースをすばやくクエリするために使用されます。インデックスの原則は、簡単に言うと、データベースの特定のフィールドのデータを並べ替えて、別の特別なインデックスデータテーブルに保存することです。次に、フィールドにクエリを実行するときに、二分法を使用して、インデックスデータテーブル内の対応するレコードのデータIDをすばやく見つけ、このデータIDに基づいて元のテーブルからクエリする必要のあるレコード情報を返します。
たとえば、データベース内のデータをライブラリ内のすべての本と見なします。次の本があるとします。
これらの本の順序は保存時間に基づいていることに注意してください。これは通常のデータの順序でもあります。つまり、最初のデータが最初に来て、後のデータが後で来ます。データベースでは、データのデフォルトの順序も時間の前から後ろに並べ替えられます。
次に、同級生が「オーストラリアのロブスターファーミングダファ」という本を持って来てくれたとしましょう。他に情報がない場合は、ライブラリ全体で1冊ずつ1冊ずつ探す必要があります。 。この本がたまたま後ろにある場合は、ライブラリ全体を検索してください。本の検索を高速化するために、インデックステーブルを作成できます。たとえば、本のタイトルの最初の文字で並べ替えます。
現時点では、「オーストラリアのロブスター繁殖ダファ」を探しています。この本のタイトルインデックステーブルで辞書のようにその位置をすばやく見つけて、各本ではなく、対応する位置に直接移動して本を入手できます。それを見つけに行きました。
特定のタイトルの本を探すことに加えて、ユーザーは他の方法を見つける必要がある場合もあります。たとえば、作者による。ある学生が、作者「張さん」の本を全部借りたいとしましょう。現時点では、上記の本名別索引表ではご要望にお応えできません。「張さん」の本を全部欲しい場合は、図書館に行って一冊一冊、つまり「トラバース」を探す必要があります。したがって、別の作成者インデックステーブルを作成できます。
張山のすべての本をすばやく見つけることができるように、著者の分類でソートされたインデックステーブル。
上記の例では、本の総数、つまりデータの総数は6つしかないため、感覚がはっきりしない場合があります。ただし、実際のデータベースアプリケーションでは、テーブル内のデータが100万を超える場合があります。現時点では、インデックステーブルとデータを最初から最後までトラバースする速度に従ってデータを見つけることは非常に明白です。
実際のデータベースでは、インデックスを実装するさまざまな方法があり、非常に複雑な技術的な詳細もありますが、基本的な原則は上記のライブラリの例と同じです。興味のある人は誰でも、さまざまなインデックスの特定の実装について詳しく知ることができます。
2.いつインデックスを追加する必要がありますか
前のセクションでは、インデックスの役割は、データベース内の特定のデータをすばやく見つけるのに役立つことを学びました。どの特定のシナリオで「データをすばやく見つける」必要がありますか？私たちの日常のデータベース操作には、実際には2つの主要な領域があります。
- 1つは、出力のフィルタリング、統計のフィルタリング、更新のフィルタリングなど、データがフィルタリングされる場合です。たとえば、データを出力するときに入力するフィールドは次のとおりです。
上記の出力では、「Zhang San」という名前のすべてのレコードを出力する必要があるため、Zhang Sanという名前のすべてのレコードを検索するには、データベースがライブラリアンのようにライブラリ全体に1つずつ移動する必要があります。 、各レコードの「名前」フィールドが「張さん」であるかどうかを確認し、そうである場合は、それを返送してください。したがって、この場合、データが多い場合は、インデックスを追加することをお勧めします。インデックスを追加した後、データベースシステムは自動的にインデックステーブルを作成して、「名前」フィールドのすべての値を特定の方法で配置します。これにより、ピンインインデックスのように張山のすべてのレコードをすばやく見つけて、私たちです。
出力、更新、統計のいずれであっても、フィルタリングを伴う限り、データベースはこれらの適格なレコードを最初に見つける必要があるため、データ量が多い場合はインデックスを追加する必要があります。
- 第二に、データをソートする場合、ソートは私たちの意見では非常に単純なタスクですが、大量のデータを含むテーブルの場合、ソートは大きなプロジェクトです。ソートにどの方法を使用する場合でも、データをすばやく見つける方法が必要です。したがって、データ量が多い場合は、ソートされたフィールドのインデックスも追加する必要があります。
最後に、記事の中で「データ量が多い」というインデックスを付ける必要があると常に述べてきましたが、データ量が多いとどのようにカウントするのでしょうか。実際、この質問に対する標準的な答えはなく、漠然とした範囲です。まず、数百個のデータは確かに大量のデータに属していません。1wを超えると、大量のデータに属します。これらの数千のデータは「大量のデータ」とは見なされません。個人的な経験に基づいて、通常5000を超えるデータをインデックスに登録することができます。5000未満の場合は必要ありません。ただし、4999は、インデックスを追加するかどうかに関係なく、インデックスにもコストがかかるため、特定のアプリケーションシナリオによって異なります。詳細については、次のセクションで説明します。
3、インデックスを追加する必要がない場合
上記では、「インデックス作成Dafa」の利点を十分に理解していますが、ivxシステムがデフォルトですべてのフィールドにインデックスを追加しないのはなぜですか。なぜわざわざ選択するのでしょうか。「世界には無料のランチがない」ため、インデックス作成にもコストがかかり、そのコストには主に次のものが含まれます。
- インデックステーブルに追加のストレージスペースが必要なため、ストレージスペースが増加しました。
- インデックステーブルの作成には一定の時間がかかり、その際データベースがロックされて操作できなくなります。したがって、データベースにすでに一定量のデータがある場合にインデックスを作成するのではなく、データベースの作成時に必須フィールドのインデックスを作成することをお勧めします。
- インデックステーブルを維持する必要があるため、インデックスを作成すると、データベースの挿入、更新、および削除の操作に時間がかかります。
したがって、インデックスが多いほど良くはありません。オンデマンドでインデックスを追加する必要があります。つまり、大量のデータを頻繁に照会するフィールドにインデックスを追加する必要があります。そうしないと、インデックスをランダムに追加すると、データ保守コストとデータ挿入サービスコストが高すぎる可能性があります。フィールドがフィルタリングやソートに使用されず、通常のデータとして出力されると仮定すると、インデックスの追加も無駄であるため、インデックスを追加する必要はありません。たとえば、非常に長いテキストの説明である「個人の説明」フィールドがあります。「個人の説明」でデータベース内のデータを検索する必要はありません。これは単なる「追加情報」フィールドです。このタイプのフィールドを追加する必要はありません。インデックス付き。
要約すると、次の状況ではインデックスを追加する必要はまったくありません。
- データの量は少なく、たとえば1000未満です。
- フィルタリングや並べ替えに使用されるフィールドはありません。
- クエリ頻度が非常に低いフィールド
第四に、iVXのデータベースのインデックス
iVXのデータベースでは、データベースの右側にあるインデックスパネルのフィールドにインデックスを追加できます。新しく作成されたデータベースの場合、システムは自動的に3つのインデックスを追加します。データIDのプライマリキーインデックス、送信ユーザー、および作成時間です。
その中で、データIDはプライマリキーインデックスとして使用され、削除することはできません。他の2つはデフォルトで追加されるため、クエリを実行する必要がない場合は、それらを削除してデータ挿入の速度を向上させることができます。
フィールドを追加したい場合は、「インデックスフィールドの追加」をクリックして、追加する必要のあるフィールドを選択できます。
インデックスを追加すると、左側に「データ固有」スイッチもあることがわかります。
このスイッチをオンにすると、フィールドインデックスは「独立した一意のインデックス」にアップグレードされます。つまり、重複データを挿入することはできません。現在のフィールドに重複するデータがある場合、このスイッチをオンにすると、ポップアップウィンドウにエラーが表示されます。独立した一意のインデックスは、データの非繰り返し性を制限するだけでなく、データクエリの効率を向上させることもできます。
5、共同インデックス
単一のインデックスを追加するだけでなく、ジョイントインデックスを追加することもできます。インデックスの右側にある「+」記号をクリックするだけです。
いわゆるジョイントインデックスは、2つ以上のフィールドの値のインデックスを同時に作成することです。その主な機能は、複数の条件のクエリを高速化することです（ここでの複数の条件は「and」条件のみを指します）。たとえば、「type」= xxおよび「region」= xxの製品をクエリする必要があることがよくあります。この時点で、「type」フィールドと「region」フィールドのジョイントインデックスを追加して、システムが自動的に実行されるようにすることができます。各データのタイプと領域の値が一緒に記録および索引付けされるため、データベースは、「type」= xxおよび「region」= xxの製品を照会するときに、対応するレコードをすばやく見つけることができます。
6、ジョイントインデックスVSシングルインデックス
a、b、cなどのNフィールドにジョイントインデックスを追加すると、3つのフィールドにジョイントインデックスが追加され、システムはフィールドインデックス、a + bフィールドジョイントインデックス、およびa + b + cフィールドを構築します。ジョイントインデックス。したがって、ジョイントインデックスの消費量が比較的多いことがわかります。いつ共同インデックスを追加しますか？主に2つのシナリオを要約しました。
- 2つ以上のフィールドがクエリの組み合わせとして使用されることが多く、これらのフィールドの組み合わせた値の多様性は、単一のフィールドのそれよりも大幅に大きくなります。たとえば、「submiting user」= xxxおよび「ordernumber」= xxxのレコードをクエリしたいが、注文番号は非常に多様なフィールドであるとします。たとえば、通常、ユーザーの注文番号は1つだけですが、場合によっては二。言い換えれば、データベースには1w個のデータがあり、9k個の注文番号があります。現時点では、注文番号の1つのフィールドのダイバーシティが9kであるため、注文番号と送信ユーザーのジョイントインデックスを追加することはあまり意味がありません。ジョイントインデックスを追加すると、ダイバーシティは9kから1wに増加するだけです。ジョイントインデックスのコストを考慮すると、現時点では追加する必要はありません。ただし、ユーザーが通常10を超える注文番号を持っている場合、この時点でユーザーXの注文番号の共同インデックスを追加すると、インデックスの多様性を大幅に高めることができます。
- 複数のフィールドの独立性と独自性は、非常に「かわいい」機能です。多くの場合、この要件があります。たとえば、ユーザーは候補者にのみ投票できます。または、ユーザーは別のユーザーを1回だけ支援でき、ユーザーは1日に1回だけ赤い封筒を受け取ることができます。共同インデックスがなくなる前は、データベースにアクセスして、ユーザーAが候補者1に投票したかどうかを確認することしかできません。ある場合は投票でき、そうでない場合は投票できません。この時点で、トランザクションを実行していない場合、高い同時実行性が発生したときにデータの不整合も発生します。しかし今では、共同で独立した一意のインデックスを使用して問題を解決し、ユーザーと候補者の共同インデックスを追加して、この共同インデックスを唯一のデータとして設定できます。
送信時に、各ユーザーを候補者ごとに1票のみに自動的に制限できます。このアプローチは、バックグラウンドのコンピューティングリソースを節約するだけでなく、データの一貫性を下から保証します。したがって、この方法を使用して、ユーザーによる投票、赤い封筒の受け取り、および賞の受け取りを制限することを強くお勧めします。（もちろん、それは万能薬ではなく、独立した一意のインデックスであり、1つのレコードのみを制限でき、ユーザーを別の候補者に2票のみ投票するように制限することはできません。複数の票に遭遇した場合は、トランザクションを使用して達成することをお勧めします。 ）
インターネット上の共同インデックスと単一インデックスの使用シナリオに関する記事は他にもたくさんあります。ここでは、最も一般的な2つの共同インデックスシナリオを要約します。あなたはインターネット上でより多くの経験記事を見つけることができます、コメントエリアで共有することを歓迎します〜