- 頻繁なクエリを判断するために使用するパターンは何ですか?
- 最適化要因をどのように選択しますか?
- どのような種類の変更を行うことができますか?
9 に答える
これは良い質問です。
私があなたを理解しているなら、あなたはゼロから最適化の問題に取り組む方法を尋ねています。
最初に尋ねる質問は、「パフォーマンスの問題はありますか?」
です。問題がなければ、作業は完了です。これはよくあることです。良い。
一方で...
頻繁なクエリを決定する
ロギングにより、頻繁なクエリが得られます。
ある種のデータ アクセス レイヤーを使用している場合は、すべてのクエリをログに記録するコードを簡単に追加できます。
クエリがいつ実行され、各クエリにかかった時間をログに記録することもお勧めします。これにより、どこに問題があるかがわかります。
また、どのビットがユーザーを悩ませているかをユーザーに尋ねます。遅い応答がユーザーを苛立たせないのであれば、それは問題ではありません。
最適化係数を選択しますか?
(質問のこの部分を誤解している可能性があります)クエリ/応答時間のパターンを探しています。
これらは通常、大きなテーブルに対するクエリ、または単一のクエリで多くのテーブルを結合するクエリです。...しかし、応答時間をログに記録すると、それらによって導かれる可能性があります。
変更の種類
あなたは具体的にテーブルの最適化について尋ねています。
探すことができるもののいくつかを次に示します。
- 非正規化。これにより、複数のテーブルが 1 つの幅の広いテーブルにまとめられるため、クエリで複数のテーブルを結合する代わりに、1 つのテーブルを読み取るだけで済みます。これは非常に一般的で強力なテクニックです。注意。元の正規化されたテーブルを保持し、さらに非正規化されたテーブルを構築することをお勧めします。この方法では、何も捨てることはありません。それをどのように最新の状態に保つかは別の問題です。基になるテーブルでトリガーを使用するか、更新プロセスを定期的に実行することができます。
- 正規化。これは最適化プロセスと見なされることはあまりありませんが、次の 2 つの場合があります。
- 更新します。正規化により、更新が大幅に高速化されます。これは、各更新が可能な限り最小であるためです (列と行に関して最小のテーブルを更新しているためです)。これは、ほぼ正規化の定義そのものです。
- 非正規化されたテーブルにクエリを実行して、はるかに小さい (行数が少ない) テーブルに存在する情報を取得すると、問題が発生する可能性があります。この場合、正規化されたテーブルと非正規化されたテーブルを保存します (上記を参照)。
- 水平パーティショニング。これは、いくつかの行を別の同一のテーブルに入れることによって、テーブルを小さくすることを意味します。一般的な使用例は、テーブル ThisMonthSales に今月のすべての行を持ち、テーブルOldSalesにすべての古い行を持ち、両方のテーブルが同一のスキーマを持つ場合です。ほとんどのクエリが最近のデータに対するものである場合、この戦略は、すべてのクエリの 99% がデータの 1% のみを参照していることを意味し、パフォーマンスが大幅に向上します。
- 垂直パーティショニング。これは、テーブルからフィールドを切り取って、主キーによってメイン テーブルに結合された新しいテーブルに配置することです。これは、非常に幅の広いテーブル (数十のフィールドなど) に役立ち、テーブルがまばらに入力されている場合に役立つ可能性があります。
- 指数。あなたの質問がこれらをカバーしているかどうかはわかりませんが、指数の使用に関する SO には他にもたくさんの答えがあります。インデックスのケースを見つける良い方法は、遅いクエリを見つけることです。クエリプランを見て、テーブルスキャンを見つけてください。そのテーブルのフィールドにインデックスを付けて、テーブル スキャンを削除します。必要に応じて、これについてさらに書くことができます - コメントを残してください.
これに関する私の投稿も気に入るかもしれません。
あなたの質問は少しあいまいです。どの DB プラットフォームですか?
SQL Server について話している場合:
- 動的管理ビューを使用します。SQL プロファイラーを使用します。SP2 とパフォーマンス ダッシュボード レポートをインストールします。
- 最もコストのかかるクエリ (つまり、実行回数 x 1 つのクエリのコスト) を特定した後、それらの実行計画を調べ、関連するテーブルのサイズと、それらが主に読み取りまたは書き込みであるか、または両方の混合であるかを調べます。
- システムが完全に制御されている場合 (アプリと DB)、派生テーブルの結合として書き直されることが多い深い相関サブクエリなど、不適切な形式のクエリ (よくあること) を書き直すことがよくあります。少し考えながら。それ以外の場合は、カバーする非クラスター化インデックスを作成し、統計が最新の状態に保たれるようにするオプションがあります。
どのシステムについて話しているのかを知らずに答えるのは難しいです。
たとえば、Oracle では、Enterprise Manager を使用すると、どのクエリが最も時間を費やしたかを確認したり、さまざまな実行プロファイルを比較したり、時間のブロックにわたってクエリを分析したりして、役立つインデックスを追加しないようにすることができます。実行する他のすべてのクエリを犠牲にして1つのクエリ。
- MySQL には、ログ スロー クエリと呼ばれる機能があります。
残りは、所有しているデータの種類とその設定方法に基づいています。
SQL サーバーでは、トレースを使用して、クエリの実行状況を確認できます。ctrl + k または l を使用
たとえば、多数のレコードを含むテーブルでフル テーブル スキャンが発生している場合は、おそらく適切なクエリではありません。
より具体的な質問をすると、間違いなくより良い回答が得られます。
テーブルが主に読み取られる場合は、クラスター化インデックスをテーブルに配置します。
私の経験では、初期の頃は主に DB2 と Oracle が少しありました。
DBMS が優れている場合は、特定のクエリに関する統計を収集し、データの抽出に使用した計画を説明する機能を備えています。
たとえば、2 つの列 (日付とディスク使用量) を持つテーブル (x) があり、日付にのみインデックスがある場合、クエリは次のようになります。
select diskusage from x where date = '2008-01-01'
インデックスを使用できるため、非常に効率的です。一方、クエリは
select date from x where diskusage > 90
それほど効率的ではないでしょう。前者の場合、「explain plan」は、インデックスを使用できることを示します。後者の場合、行を取得するためにテーブル スキャンを実行する必要があると言えます (基本的には、すべての行を調べて、一致するかどうかを確認します)。
本当にインテリジェントな DBMS は、パフォーマンスを改善するために何をすべきかを説明することもあります (この場合、ディスク使用量にインデックスを追加します)。
どのクエリが実行されているかを確認する方法については、DBMS から収集するか (許可されている場合)、ストアド プロシージャを介して全員にクエリを実行させて、DBA がクエリの内容を制御できるようにすることができます。 DB が効率的に実行されます。
1. 頻繁なクエリを判断するために使用するパターンは何ですか?
データベースを扱っているレベルによって異なります。あなたが DBA であるか、ツールにアクセスできる場合、Oracle のようなデータベースを使用すると、指定した期間にわたってジョブを実行し、統計/レポートを生成できます。データベースに対してアプリケーションを作成する開発者であれば、アプリケーション内でパフォーマンス プロファイリングを行うことができます。
2. 最適化要因はどのように選択しますか?
テーブルがどのように使用されているか、テーブルに含まれているデータについて、一般的な感覚を掴もうとしています。以下の質問に答えます。
大量に更新されるのでしょうか? また、どのフィールドで更新が行われるのでしょうか? カーディナリティの低い列はありますか?
インデックスする価値はありますか?(非常に小さいテーブルは、インデックスでアクセスすると速度が低下する可能性があります)
より高速に実行するために、どれだけのメンテナンス/頭痛の価値がありますか?
更新/挿入とクエリの比率?
等
3. どのような変更を加えることができますか?
-- Oracle を使用している場合は、統計を最新の状態に保ってください。=)
-- 正規化/非正規化は、テーブルの使用状況に応じてパフォーマンスを向上させることができます。私はほとんどの場合正規化しますが、他の実用的な方法でクエリを高速化できない場合にのみ、非正規化します。クエリを非正規化する良い方法は、状況が許せば、実際のテーブルを正規化したままにして、マテリアライズド ビューを持つ非正規化された「テーブル」を作成することです。
-- 慎重に索引付けしてください。多すぎると、多くのレベルで問題になる可能性があります。列を頻繁に更新せず、その列のカーディナリティが低い限り、BitMap インデックスは Oracle で優れています。
-- インデックス編成テーブルの使用。
-- パーティション化およびサブパーティション化されたテーブルとインデックス
-- ストアド プロシージャを使用して、アプリケーションによるラウンド トリップを減らし、セキュリティを強化し、ユーザーに影響を与えることなくクエリの最適化を有効にします。
-- 必要に応じてテーブルをメモリにピン留めします (頻繁にアクセスされ、かなり小さい)。
-- インデックス データベース ファイルとテーブル データベース ファイル間のデバイス パーティショニング。
.....リストは続きます。=)
これがお役に立てば幸いです。
PK と FK のインデックスと、常にパーティショニングに役立つ 1 つのこと...