クエリチューニングはプロアクティブかリアクティブか

ソフトウェア開発者および意欲的なDBAとして、SQL Serverデータベースを設計するときにベストプラクティスを取り入れようとしています（ソフトウェアがSQL Serverの上に置かれる時間の99％）。開発前および開発中に可能な限り最高の設計を行います。

ただし、他のソフトウェア開発者と同様に、機能、バグ、および変更/作成されたデータベースオブジェクトを必要とする要件の変更が追加されています。

私の質問は、クエリのチューニングはプロアクティブかリアクティブですか？言い換えれば、コード/データベースの大幅な変更の数週間後、クエリのパフォーマンスをチェックし、それに基づいてチューニングするために1日だけを確保する必要がありますか？それが実行されているように見える場合であっても大丈夫？

または、平均以下のパフォーマンスはデータベースチェックであり、ことわざにある黒板に戻るべきであることに注意する必要がありますか？

クエリのチューニングには多くの時間がかかる可能性があり、データベースの初期設計によっては、メリットが最小限になる場合があります。私は受け入れられている手口について興味があります。

両方、ただし主に予防的

開発中に、現実的な量と品質のデータに対してテストすることが重要です。100行または1000行の開発者でクエリを実行した後、1000万本の実稼働行でフラットになることは信じられないほど一般的です。

「インデックスはここで役立つ可能性があります」についてもメモすることができます。または「再訪」。または、「次のDBバージョンの新機能xxxで修正します」。

ただし、いくつかのクエリは時の試練に耐えません。オプティマイザーが異なる結合タイプを使用することを決定したため、データ分布が変化するか指数関数的になります。この場合、反応できるのはあなただけです。

少なくともSQL Serverの場合、さまざまな「欠落したインデックス」および「最長のクエリ」DMVクエリは、電話をかける前に問題領域を示すことができると言っています

編集：明確にするために...

プロアクティブとは、すべてのクエリをすぐに調整することではありません。つまり、必要なものを実行（頻繁に実行）して適切な応答時間に調整します。毎週午前3時の日曜日のレポートクエリはほとんど無視します。

さて、私は噛んで反対の見方をします。まず、トラブルにつながるとわかっていることをやることから始めてはいけないと言います。ベストプラクティスを適用してこれを呼び出したい場合は、先に進んでください。これは、プロアクティブである限りです。

その後、時間の浪費（そしてお金の浪費）が続くので、それを試して製品を届けてください。ボトルネックになる可能性のあるまたはまったくないクエリを設計時に調整する代わりに、負荷テストを含む追加のテストにその時間を使用します。

設計仕様どおりに機能していないことが判明した場合、またはプロファイラーの応答時間のリストの下位10％または20％に何かが入っている場合は、それが何であるかを微調整するために必要な時間を投資します壊れた。

完全な世界では、すべてが最初から完全に設計され、論理的なビルドシーケンスを使用して開発されます。現実の世界では、予算と時間に制約があり、テストデータが実稼働データのように見えない場合があります。このため、常識を使って問題を予防的に回避しますが、想像上の問題や潜在的な問題を探すのにおそらく時間とお金を費やすのではなく、限られたリソースを集中して実際の問題になります。

1つの事後対応型と2つの事前対応型の3種類のチューニングを行います。

リアクティブ

突然、一部のクエリが開始され、問題が発生します。これは、アプリケーションのバグや機能、予想を超えるテーブルの増加、トラフィックの急上昇、またはクエリオプティマイザーが「創造的」になっていることが原因である可能性があります。これは、深夜のサイトのダウンタイプの問題かもしれませんし、重要でない性質のシステムのスローダウンに対応しているかもしれません。いずれにせよ、リアクティブチューニングの特徴は、すでに問題があることです。言うまでもなく、あなたはこれをできる限り少なくしたいと思っています。それは私たちに...をもたらします

積極的

タイプ1：定期メンテナンス

スキーマの変更頻度とデータの成長速度に応じて、数か月または数週間ごとに何らかのスケジュールで、データベースのパフォーマンス分析ツールの出力を確認する必要があります（Oracle DBAのAWRレポートなど）。あなたは、初期の問題を探しています。それは、リアクティブなチューニングを必要とする方法に加えて、すぐに問題を引き起こす可能性が低いが、遠くを防ぐことを期待して少しの努力で改善できるアイテムです。 -将来の問題。これにどれだけの時間を費やすべきかは、あなたがどれだけの時間を費やしているか、そして何に費やすことができるかに依存しますが、最適な量は決してゼロではありません。ただし、次のことを行うことで、必要な金額を簡単に減らすことができます。

タイプ2：適切な設計

「時期尚早の最適化」に対するKnuthの忠告は広く知られており、正当に尊重されています。ただし、「時期尚早」の適切な定義を使用する必要があります。一部のアプリケーション開発者は、独自のクエリの作成を許可された場合、最初にヒットしたクエリを論理的に正しいものとして採用する傾向があり、現在または将来のパフォーマンスにまったく気にしません。または、単に本番環境を代表していない開発データセットに対してテストする場合があります（ヒント：これを行わないでください！開発者は常に、テストのために現実的なデータにアクセスできる必要があります）。重要なのは、クエリを調整する適切なタイミングは、パフォーマンスの低いSQLのリストに表示されるときではなく、最初に展開されるときであり、重大な問題を引き起こすときではないことです。

それでは、DBAの土地での時期尚早な最適化とは何でしょうか？私のリストの一番上にあるのは、実証された必要なしに正規化を犠牲にすることです。実行時に子行から計算するのではなく、親行の合計を維持することはできますが、本当に必要ですか？TwitterまたはAmazonの場合、戦略的な非正規化と事前計算が親友になります。5人のユーザー用の小さなアカウンティングデータベースを設計している場合、データの整合性を促進する適切な構造を最優先する必要があります。他の時期尚早な最適化も同様に優先順位の問題です。0.1秒に短縮できると思っていても、1日に1回実行され、10秒かかるクエリを微調整するのに何時間も費やさないでください。毎日6時間実行されるレポートがあるかもしれませんが、チューニングに時間をかける前に、バッチジョブとしてスケジューリングすることを検討してください。プロダクションの負荷が10％を超えて変動しない場合は、個別のリアルタイムのレプリケートされたレポートインスタンスに投資しないでください（セキュリティを管理できる場合）。

現実的なデータに対してテストし、成長とトラフィックパターン（およびスパイクの許容値）について知識に基づいた推測を行い、プラットフォームのオプティマイザーの癖に関する知識を適用することで、現在だけでなく将来的に最適に（ほぼ）実行されるクエリを展開できます、および理想的でない条件の下で。適切な手法を適用すると、クエリのパフォーマンスを正確に予測および最適化できます（各コンポーネントが必要なだけ高速であるという意味で）。

（そして、あなたがそこにいる間に、統計を学んでください！）

完璧な世界では、すべてのチューニングは設計段階で積極的に行われ、リアクティブではありませんが、世界は完璧ではありません。テストデータが代表的ではない場合や、テストケースが欠落している場合、負荷が予想外に異なる場合、パフォーマンスの問題を引き起こすバグがある場合があります。これらの状況では、リアクティブチューニングが必要になる場合がありますが、それはリアクティブチューニングが推奨されることを意味しません。目標は常にこれらを事前に把握することです。

遡及調整の計画は非常に実用的です。テストするときは、予想されるタイミングとスループットを文書化する必要があります。実際には、生産プロセスが設計仕様を満たしていないことを知らせる分析を実際に組み込む必要があります。この方法で、どのコードを調整する必要があるかを事前に識別できる場合があります。そうすることで、問題が何であるかだけでなく、設計/テスト段階でなぜそれを見つけられなかったのかを判断できます。

私にとって、パフォーマンステストは常に開発プロセスの一部でした。この表を変更し、このレポートを変更し、この機能を追加しますか？テストの一環として、個々のパフォーマンスと全体的なパフォーマンスを既知のベースラインおよび/または要件と比較できることを確認します（たとえば、一部のレポートはバックグラウンドで実行されるか、自動化されているため、システムが常に最優先事項とは限りません）。

私見、これはリアクティブなプロセスであってはなりません-変更が本番環境でパフォーマンスの問題を引き起こし、それに反応し始めるまで決して待つべきではありません。dev / testなどで変更を行うときは、同じアプリと同じ使用パターンを持つ同じハードウェアで、同じデータを使用してそれらの変更をテストする必要があります。これらの変更を実稼働環境に急いで行って驚かないでください。これは、ほとんどの場合、1日の調整に費やすことが都合の悪いときに発生します。その調整時間の予算は、事前に十分です。