Sql-database-tuning

SQL-データベース調整

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

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

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

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

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

• 説明計画-ツールは、SQLステートメントの実行時に使用されるアクセスパスを識別します。
• tkprof -SQLステートメント処理の各フェーズ中に経過した時間でパフォーマンスを測定します。

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

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