SQL-データベースの調整

データベースエキスパートまたはエキスパートデータベース管理者になるには時間がかかります。これにはすべて、さまざまなデータベース設計と優れたトレーニングの経験が豊富です。

ただし、次のリストは、初心者がデータベースのパフォーマンスを向上させるのに役立つ場合があります。

このチュートリアルのRDBMSの概念の章で説明されている3BNFデータベース設計を使用します。
数字と文字の比較が異なり、パフォーマンスが低下するため、数字から文字への変換は避けてください。
SELECTステートメントを使用している間は、必要な情報のみをフェッチし、システムを不必要にロードするため、SELECTクエリで*を使用しないでください。
検索操作が頻繁に行われるすべてのテーブルに、慎重にインデックスを作成してください。検索操作の数が少なく、挿入および更新操作の数が多いテーブルのインデックスは避けてください。
全表スキャンは、WHERE句の列にインデックスが関連付けられていない場合に発生します。SQLステートメントのWHERE句で条件として使用される列に索引を作成することにより、全表スキャンを回避できます。
実数と日付/時刻値を持つ等価演算子には十分注意してください。これらは両方とも、目には明らかではないが完全一致を不可能にする小さな違いがある可能性があるため、クエリが行を返すことはありません。
パターンマッチングは慎重に使用してください。LIKE COL％は有効なWHERE条件であり、返されるセットを、文字列COLで始まるデータを持つレコードのみに減らします。ただし、％Yを効果的に評価できないため、COL％Yは返される結果セットをさらに削減しません。評価を行うための努力は、考慮するには大きすぎます。この場合、COL％が使用されますが、％Yは破棄されます。同じ理由で、先頭のワイルドカード％COLは、フィルター全体が使用されるのを効果的に防ぎます。
クエリ（およびサブクエリ）の構造、SQL構文を調べて、SQLクエリを微調整し、高速データ操作をサポートするようにテーブルを設計し、最適な方法でクエリを記述して、DBMSがデータを効率的に操作できるようにしたかどうかを確認します。。
定期的に実行されるクエリの場合は、プロシージャを使用してみてください。プロシージャは、潜在的に大きなSQLステートメントのグループです。プロシージャはデータベースエンジンによってコンパイルされてから実行されます。SQLステートメントとは異なり、データベースエンジンは、実行前にプロシージャを最適化する必要はありません。
可能であれば、クエリで論理演算子ORを使用しないでください。または、かなりのサイズのテーブルに対するほぼすべてのクエリの速度が必然的に遅くなります。
インデックスを削除することで、バルクデータのロードを最適化できます。何千もの行がある履歴テーブルを想像してみてください。その履歴テーブルにも1つ以上のインデックスがある可能性があります。インデックスについて考えるとき、通常はより高速なテーブルアクセスを考えますが、バッチロードの場合は、インデックスを削除することでメリットが得られます。
バッチトランザクションを実行する場合は、レコードを作成するたびに作成するのではなく、かなりの数のレコードを作成した後にCOMMITを実行します。
毎週のルーチンを開発することを意味する場合でも、定期的にデータベースを最適化することを計画してください。

組み込みのチューニングツール

Oracleには、SQLステートメントのパフォーマンスを管理するための多くのツールがありますが、そのうち2つは非常に人気があります。これらの2つのツールは-

Explain plan −ツールは、SQLステートメントの実行時に使用されるアクセスパスを識別します。
tkprof −SQLステートメント処理の各フェーズで経過した時間によってパフォーマンスを測定します。

Oracleでクエリの経過時間を単純に測定する場合は、SQL * PlusコマンドSETTIMINGOを使用できます。

上記のツールとデータベースの最適化の詳細については、RDBMSのドキュメントを確認してください。