データベースは内部的にどのように機能しますか? [closed] 質問する

データベースは、選択ステートメントに一致するものを見つけるために実際に何を行うのでしょうか?

率直に言えば、これは力ずくの問題です。簡単に言えば、データベース内の候補レコードをそれぞれ読み取り、式をフィールドに一致させます。つまり、「select * from table where name = 'fred'」とすると、文字通り各レコードが実行され、「name」フィールドが取得され、それを 'fred' と比較します。

ここで、「table.name」フィールドにインデックスが付けられている場合、データベースは (おそらく、必ずではありませんが) 最初にインデックスを使用して、実際のフィルターを適用する候補レコードを検索します。

これにより、式を適用する候補レコードの数が減ります。そうでない場合は、いわゆる「テーブル スキャン」、つまりすべての行の読み取りが実行されます。

しかし、基本的には、候補レコードを見つける方法と実際のフィルター式を適用する方法は別であり、明らかに、実行できる巧妙な最適化がいくつかあります。

データベースは、複数の「where key1 = key2」ステートメントを含むクエリとは異なる方法で結合を解釈しますか?

結合は、新しい「疑似テーブル」を作成するために使用され、その上にフィルターが適用されます。つまり、フィルター基準と結合基準があります。結合基準は、この「疑似テーブル」を作成するために使用され、その後、フィルターがそれに適用されます。結合を解釈するときには、フィルターと同じ問題、つまり「疑似テーブル」のサブセットを作成するための総当たり比較とインデックス読み取りが再び発生します。

データベースはどのようにしてすべてのメモリを保存するのでしょうか?

優れたデータベースの鍵の 1 つは、I/O バッファの管理方法です。ただし、基本的には RAM ブロックをディスク ブロックに一致させます。最新の仮想メモリ マネージャーを使用すると、よりシンプルなデータベースは、メモリ バッファ マネージャーとして VM にほぼ依存できます。ハイエンドの DB は、これらすべてを独自に実行します。

インデックスはどのように保存されますか?

B+ツリーは一般的に、調べる必要があります。これは、何年も前からある簡単なテクニックです。その利点は、ほとんどのバランスのとれたツリーに共通しています。つまり、ノードへの一貫したアクセス、さらにすべてのリーフ ノードがリンクされているため、キーの順序でノードからノードへ簡単に移動できます。したがって、インデックスを使用すると、行はデータベース内の特定のフィールドに対して「ソート済み」であると見なされ、データベースはその情報を活用して最適化を行うことができます。これは、たとえば、特定のレコードにすばやくアクセスできるインデックスにハッシュ テーブルを使用する場合とは異なります。B-ツリーでは、特定のレコードにすばやくアクセスできるだけでなく、ソートされたリスト内のポイントにもすばやくアクセスできます。

データベースに行を保存してインデックスを作成する実際の仕組みは、非常に単純で、よく理解されています。重要なのは、バッファを管理し、SQL を効率的なクエリ パスに変換して、これらの基本的なストレージ イディオムを活用することです。

さらに、ストレージの慣用句に加えて、マルチユーザー、ロック、ログ記録、トランザクションの複雑さも存在します。