データベース・パフォーマンス・アナライザ (DPA) 2024.4 : MySQL および Percona MySQL 用チューニング・アドバイザをサポート

投稿日: 2024年11月12日 作成者: climb
このエントリーをはてなブックマークに追加
LINEで送る

MySQL/Percona MySQL用テーブルチューニングアドバイザー

すべてのデータベースには非効率的なクエリが存在します。つまり、少ないリターンに対して多大な労力を費やしているます。この非効率性は、高い入出力、長い待ち時間、より多くのブロック、リソースの競合の増加につながる可能性があります。

非効率的なクエリのチューニングは困難であり、そのプロセスにおいて多くの疑問が生じがちです。例えば、

    • クエリをチューニングすべきか？ 新しいインデックスを追加すべきか？ あるいは、既存のインデックスに列を追加すべきか？
    • プランは複雑で分析が困難です。どのステップを考慮すべきでしょうか？
    • プラン内のどの条件が非効率なデータアクセスや大量の読み取りを引き起こしているのでしょうか？
    • 出発点として使用できる推奨事項はあるでしょうか？
    • 同じテーブルにアクセスする他の非効率なクエリがあり、インデックス作成の決定に影響される可能性があるでしょうか？
    • 現在、テーブルにいくつインデックスが存在し、それらはどのように構成されていますか？
    • テーブル内のデータは、データの更新（挿入、削除、および場合によっては更新）の頻度から見て、どの程度トランザクション性が高いですか？

Table Tuning Advisorは、これらの疑問の解決に役立ちます。

Table Tuning Advisorは、高価なクエリを分析し、その理由に関わらず、非効率的なワークロードが実行されているテーブルを特定するのに役立ちます。各テーブルについて、アドバイザーページには、テーブルと非効率的なクエリに関する集約された情報が表示されます。この情報を利用して、データベースのパフォーマンス最適化の機会について、より適切な判断を下すことができます。また、インデックスを追加した場合の潜在的なコストとメリットを比較検討することもできます。

ナビゲーション

アドバイザーページにアクセスするには、2つの方法があります。

    • インスタンスをクリックした後、ページの上部に「チューニング」というスーパー・タブが表示されます。これをクリックすると、クエリ、インデックス、およびテーブル・チューニング・アドバイザーを組み合わせたページに移動します。

・特定のクエリパフォーマンス分析（QPA）ページにドリルダウンしたら、テーブルチューニングアドバイザセクションまでスクロールダウンします。このセクションでは、テーブルレベルに集約されたアドバイスが要約され、アドバイザ詳細ページへのリンクが含まれています。

アドバイザーのページレイアウト

テーブル調整アドバイザーのページには、選択したオブジェクトに関連する重要な情報がぎっしりと詰まっています。 主な領域は次の3つです。

  • 非効率なSQL：テーブルにアクセスするクエリのリストを、相対的な作業負荷でランク付けしたもの
  • SQLおよびプランの詳細：選択したクエリのSQLおよびプランの詳細
  • テーブルおよびインデックス情報：現在のテーブル情報、テーブル上の既存のインデックス、テーブルの列

テーブルチューニングアドバイザーの例

先を見越して、何かをチューニングして大きな影響を与えたいと仮定してみましょう。 概要レベルでは、チューニングタブに非効率なクエリを持つテーブルが表示され、非効率なワークロードに基づいてそれらのテーブルがランク付けされます。 このリストには、各テーブルの待機時間の集約ビューと、テーブル上の非効率なプランステップを持つクエリの数が含まれています。 これらはチューニングの絶好の機会です。

出発点として使用する推奨事項はあるか？

「orders」テーブルをクリックすると、テーブルにアクセスする非効率的なクエリの詳細が記載されたテーブルチューニングアドバイザのページに移動します。このページには、非効率的な使用パターン、統計情報、現在のインデックスの設計など、テーブルについて知っておくべきことがまとめられています。

プランのどのステップが非効率ですか？

DPAは独自のアルゴリズムを使用して、非効率なプランステップと問題の原因を特定します。非効率な「プロデューサー」ステップ（例：フルテーブルスキャン/インデックススキャン）は、後続のコンシューマー・プラン・ステップで後から処理されるデータを読み取ります。コンシューマー・ステップ（例：ソート）は高いコストを伴うことがありますが、通常は、過剰なデータを読み取る先行のプロデューサー・ステップの影響を受けます。DPAは、チューニングの対象として、非効率なプロデューサー・プラン・ステップを指摘することができます。

上の図では、DPAは使用されている2つのプランと、それぞれのプランにおける非効率なステップを特定しています。

  1. SEQ SCAN—ステップ7: 「customer」テーブルのシーケンシャル・スキャン。 述語値が同様の比較を示していることに注目してください。 シーケンシャル・スキャンにより、一致する電話番号の150,000行が検査されました。

この情報を手動プラン分析で取得するには、おそらく何時間もかかるでしょう。プラン分析は困難な作業です。そこで、Table Tuning Advisor を使用して、最適な出発点を見つけましょう。

このテーブルへのアクセスで、他に非効率的なクエリはありますか？

Table Tuning Advisor ページの左側のペインには、「customer」テーブルへのアクセスで、相対的な作業負荷でランク付けされた、他の非効率的なクエリが表示されます。このリストの上位にあるクエリは、テーブルに対する負荷が大きいので注意してください。逆に、相対的な負荷が小さいリストの下位にあるクエリには、それほど時間を費やす必要はありません。インデックスの追加や変更などのわずかな調整が、多くの非効率的なクエリに大きな違いをもたらすこともあります。

テーブルにはいくつインデックスが存在し、どのように設計されているでしょうか？

テーブル・チューニング・アドバイザのページの下部には、現在のインデックスとカラム、統計および使用状況に関する情報が表示されます。その他のテーブルおよびインデックスのメタデータは、リアルタイムのクエリの後、最新の情報として表示されます。これは、いくつかの理由で重要です。

  • テーブルのデータ更新頻度は高いですか？もしそうであれば、挿入/更新/削除の頻度が高く、新しいインデックスは有益よりも有害となる可能性があります。
  • 述語で呼び出された列を含む既存のインデックスが役立つ可能性はありますか？新しいインデックスを作成するよりも、このクエリに役立つようにインデックスを修正することは可能ですか？
  • オプティマイザ統計は最近生成されましたか？生成されていない場合、かつ更新頻度が高い場合は、テーブルの統計を更新することが優れた第一歩となる可能性があります。
  • インデックスが肥大化していますか？肥大化している場合、かつスキャンがインデックスに対して実行されている場合は、バキューム処理プロセスの健全性を確認してください。

新たな発見は？ あるDPAユーザの開発チームは、DPAを使用してコードのパフォーマンス向上に役立てています。テーブルチューニングアドバイザーを使用したところ、問題のあるテーブルのセットを指摘されました。数時間以内に簡単な書き換えでクエリをチューニングし、毎晩のクリーンアッププロセスでデータベース時間を数時間節約することができました。

関連したトピックス

コメントを残す

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください。