5.3チューニングとキャパシティ設計

データベース設計者・DBAにとって、性能問題への対処は「インデックスを張る」だけでは終わりません。テーブル構造そのもの（非正規化・パーティショニング）を見直す判断、SQL文の書き方を変える判断、そして「本当のボトルネックがどこにあるか」を診断する判断まで含めて初めて、持続的なチューニングができます。この節ではそうした設計・診断の判断力を養います。

5.3.1非正規化とパーティショニング

• 非正規化＝正規化によって分解されたテーブルを、参照性能を優先する目的で意図的に結合・冗長化する設計判断。例えば注文明細に商品名を都度JOINで取得する代わりに、注文明細テーブル自体に商品名を冗長に持たせれば結合コストを削減できる。ただし、商品名を後から変更した際に複数箇所を同時に更新しないと不整合が生じるという更新時異常のリスクを引き受けることになる。
• パーティショニング＝1つの論理テーブルを、特定のキー（日付・地域等）に基づいて物理的に複数の領域（パーティション）へ分割して格納する技術。レンジパーティショニング（日付範囲等の区間で分割）・ハッシュパーティショニング（ハッシュ値で均等に分割）等の方式がある。クエリの条件が特定パーティションに絞り込める場合、該当パーティションだけを読めばよく（パーティションプルーニング）、テーブル全体を走査するより高速になる。加えて、古いパーティション単位でのアーカイブ削除も容易になる。

5.3.2SQLチューニングとボトルネック診断

• SQLチューニング＝実行計画・インデックス構成を変えずとも、SQL文の書き方自体を見直すことで性能を改善する手法。例えばSELECT *で不要な列まで取得している場合に必要な列だけへ絞る、相関副問合せをJOINへ書き換える、OR条件で複数のインデックスが使えない場合にUNIONへ分解する、といった書き換えが該当する。
• ボトルネック診断＝性能劣化の原因が、CPU（複雑な演算・大量の結合処理）・メモリ（ソート/ハッシュ結合のバッファ不足によるディスクスワップ）・ディスクI/O（インデックス未整備による大量の物理読み込み）・ロック待ち（同時実行制御による排他）のどこにあるかを、実測データに基づいて切り分けるプロセス。原因を誤って特定すると、的外れな対策（例：ロック待ちが原因なのにインデックスを増やす）に時間を浪費する。