この記事はミック[著]SQL実践入門の第一章を要約した記事になります。

記憶装置（ストレージ）の階層分類

記憶装置はシステムがデータを保存するための装置ですが、記憶装置は装置の値段あるいはアクセスの速さによって３つに分けることができます。
例えば、メモリは他の記憶装置に比べてかなり高価ですが、HDDはメモリより断然安い上にかなりの容量があります。
価格ドットコムを見てみると、CT2K8G4DFS824A というメモリ(一枚当たり8GB)は2枚セットで18,999円するのにたいして、WD40EZRZ-RT2というＨＤＤは4TBで9389円です。
価格と容量だけみるとＨＤＤの方が良さそうにみえますが、その分アクセスのスピードは遅くなってしまいます。
逆にメモリは高価な分、アクセスのスピードはＨＤＤに比べて断然速いです。
従って、容量や価格、保管性を取れば速度が犠牲になると押さえておけば大丈夫です。
またデータベースではデータを保存する媒体としてHDDが圧倒的に使われています。

賢くメモリを使い、アクセス速度を向上させる

メモリはとても高価なため、HDDに比べて収容できる容量が限られます。
データベースシステムではよくアクセスされるデータをうまくメモリ上に保持しておくことで、保持されたデータはメモリのアクセスだけで処理を返すことができるので、圧倒的にアクセスが速いです。
このようなアクセス速度の向上のために、データを保持するメモリをバッファあるいはキャッシュと呼びます。
また、データをどのくらいの期間載せておくかということを管理する機能を、バッファマネージャといいます。

データキャッシュとログバッファ

データベースシステムが使用するメモリは大きく分けて、データキャッシュとログバッファの2種類あります。
データキャッシュはＨＤＤ上にあるデータの一部を保管する領域になります。
そして、頻繁にアクセスされるデータが保管されます。
ログバッファはデータベースを更新(INSERT、DELETE等)した時にバッファ上に更新情報が保管される場所になります。
なぜ直接ＨＤＤに更新の書き込みを行わないのかというと、ＨＤＤへの更新の書き込みはとても時間がかかるので結果的に、ユーザーを長時間待たせてしまいます。
したがってデータベースでは利便性向上のため、ＨＤＤに更新の書き込みが行われていないにも関わらず、ログバッファ上に書き込みが行われた時点でユーザに更新完了を知らせる仕組みをとっています。
また、メモリは揮発性をもっており、つまるところ電源を落とした瞬間メモリ上のデータは全て消えるので、データベースシステムでは必ずコミットのタイミングで更新情報をログファイルに書き込んでいます。

データキャッシュとログバッファのサイズ

データキャッシュとログバッファのデフォルトサイズを比較してみると、ＭＹＳＱＬではデータキャッシュの初期値が128Mバイトに対して、ログバッファの初期値は8Mバイトしかありません。
その理由はデータベースは基本的に検索処理がよく使われるだろうと想定されているからです。
データキャッシュは頻繁にアクセスされるデータの一部を保管することでスピードを速めるためのメモリ領域でした。
ただし、更新を頻繁に大量に行うデータベース(バッチ処理等)に関してはこの限りではありません。そのときはログバッファに多くのメモリを割り当てる場合もあります。

クエリ評価エンジン

DBMSにおいて、クエリ評価エンジンはユーザーから受け取ったクエリを最初に受け取る部分であり、4つのモジュール(部品)から構成されています。

①パーサー

パーサー(Parser)とは構文解析という意味です。パーサーの役割は受け取ったクエリが正しいかどうか確認することとクエリを定型的な形式に変換して後の処理を効率化する役割を担っています。
プログラミング言語のコンパイル時に実行されるのと同じです。

②オプティマイザ

オプティマイザは英語のoptimizeから由来していて、最適化という意味です。
ここでの最適化とは最適にデータをアクセスするための実行計画という意味です。
オプティマイザはインデックスがあるかどうか・データの分散や偏りの具合などの条件を考慮して、いくつかの実行計画を作成してそれらのプランのコストを計算した後、最も低いコストの実行計画一つを選出します。

③カタログマネージャ

カタログマネージャはテーブルやインデックスなどの統計情報が格納されていて、その統計情報をオプティマイザに提供しています。
統計情報には
・各テーブルのレコード数
・各テーブルの列数と列のサイズ
・列値のカーディナリティ(カーディナリティについてはカーディナリティについてまとめてみた)
・列値のヒストグラム
・列値のNULL数
・インデックス情報
　が格納されています。
注意してほしいのは**テーブルの値が大きく更新されたら、カタログの統計情報も更新して(analyze table等)**あげないといけません。
統計情報を更新しないとカタログマネージャがオプティマイザに更新する前の統計情報を渡してしまうからです。
SQLによって統計情報を自動で更新する機能があるのかどうかは不明です。

④プラン評価

よくわかりませんでしたがとりあえずExplainをつかうとどのように実行計画が選択されているか分かるので、補正案を考えることができます。

次回

結合辺りをまとめたいと思います。