テストデータは高速であるが本番環境では低速なストアドプロシージャをチューニングする方法
SQL Server 2012データベースにテストデータが含まれていて、開発段階と運用前段階にあり、会社のサーバーからの実際のデータが運用段階でのみ発生する場合つまり、実際のデータは本番フェーズでのみ発生し、テストおよび本番前フェーズでは発生しません。
生産段階は社内のサーバー内で行われます。
運用フェーズでデータを取得するのに長い時間がかかるストアドプロシージャがあり、パフォーマンスチューニングを行う必要がある場合。
この特定のストアドプロシージャは、Webページの重要な機能の一部です。ストアドプロシージャは毎日使用されます。
私の質問は：
実際のデータに関連して、本番フェーズでパフォーマンスチューニングを行うことをお勧めしますか？
知っておくべきことですか？今日、私はパフォーマンスチューニングの初心者です。
データベースとその特定のストアドプロシージャのパフォーマンスを確認するために、どのプラグインまたはツールを使用しますか？
ありがとう！
「パフォーマンス」は、ここで想定しているよりもはるかに広いトピックです。パフォーマンスに影響を与えるかなりの数の要因があります：
データモデル：適切なデータ型を使用していますか？主キーと外部キーが定義されていますか？ルックアップテーブルの代わりに繰り返し文字列値（悪い）がありますか？適切な構造、または複雑で複雑な構造を持つものはありますか？
テーブル内の行数：すべてが等しい場合、クエリオプティマイザーは、各クエリに含まれるテーブルの全体的な行数に応じて、異なる方法で処理を実行できます。したがって、（分散の違いだけでなく）根本的に異なるデータ量の環境でのテストでは、パフォーマンスではなく機能のみをテストできます。
データ値の分布：これは明らかにインデックスに関連付けられた統計に影響を与えますが、「統計の自動作成」オプションが有効になっている（そしてそれがデフォルトである）と仮定すると、任意の列がフィルタリングおよび/またはソートには、システムが作成した統計を関連付けることができます。
Indexes：インデックスがデータの検索に役立つという事実は明白ですが、誤って定義されたインデックスは時々傷つくことがあります。また、インデックスが多すぎると、DML操作が（特に、使用可能なハードウェアと競合に関して）簡単に損なわれる可能性があります。
最新の統計：環境間で同じインデックスとまったく同じデータを使用していても、統計が古くなっている場合でも、クエリオプティマイザーでパフォーマンスの問題が発生する可能性があります。特定のインデックスを使用することを知っているか、古い行の見積もりが原因で誤ってアクセスする。
競合：システム上で実行されている他のクエリは何ですか？プロダクションは当然、開発/ QA/UATシステムよりもはるかに多くの同時使用があります。より多くの同時クエリはより多くのロックとより少ない利用可能なハードウェアリソースを意味します。
コード：通常、目標を達成するにはいくつかの方法がありますが、根本的に異なる要件がある場合があります。恐ろしいものから偉大なものまで、さまざまなクエリを作成する方法はたくさんあります。そして、他の方法よりもはるかに良いまたは悪い操作を構造化する方法があります。多くの場合、これらの他の要因に関係なく、クエリやプロセス構造の小さな変更でも大きな影響を与える可能性があります。
ハードウェア： RAM（存在量、使用速度、使用可能量）、CPU（コア数、コア数、コア数） SQL Serverに割り当てられている、利用可能な容量）、およびディスクI/O（ディスクの種類：SATA vs SAS vs？、NAS vs SAN vsローカルvs？、RAIDレベル、SSD vs非SSDなど、利用可能なスループット）これらすべての領域で、システムで実行されている他のプロセスがRAM、CPU、およびI/Oを占有する可能性がありますは、SQL Serverで使用できる合計量の量に影響します。つまり、SQL Serverの外部の1つ以上のプログラムがそのCPUの大部分を使用している場合、大量のCPUは役に立ちません。
構成：スナップショットの分離、統計の非同期更新、自動拡張、自動縮小などがパフォーマンスに影響を与える可能性があります。開発/ QA /本番環境で同じように構成されていますか？最初から正しく構成されていますか？
一般的に言って、ほとんど非効率的なコードや構造でも、ほとんどの開発環境やQA環境では十分に高速に動作するように見えます。データが100〜1000行しかないため、データモデリングやコーディングにおける不適切な選択が隠されます。
少なくとも、非運用環境では、運用とまったく同じ構造と構成（テーブル、インデックス、データベース、サーバーなど）が必要です。この段階では、優れたスケーラブルなデータモデルと優れたT-SQLコーディングに焦点を当てる必要があります。
インデックスは、実行計画に影響を与えるため、代表的なデータセット（ボリュームと分布）を必要とするため、少しトリッキーです。これは、1つ以上のテスト環境（QA、UAT 、?）で実行できます。完全なサイズのために、このデータをより低い環境に取り込むことができない場合は、本番環境で行う必要があります。
ただし、これを使用しても、実際のパフォーマンスチューニングは本番環境でのみ実行できます。これは「現実」であり、他の環境はそうではないためです（ハードウェアだけでなく、使用量/負荷もなんとか複製できない限り）。したがって、より低い環境で最善の教育を受けた推測を行いますが、それが本番環境になって初めて最終的に知ることができます。コードの変更をテストする場合、理想的な環境で並べて比較できるように、グローバルな一時ストアドプロシージャを作成すると便利です。
実稼働フェーズでデータを取得するのに時間がかかるストアドプロシージャがあり、パフォーマンスチューニングを行う必要がある場合。
この特定のストアドプロシージャは、Webページの重要な機能の一部です。ストアドプロシージャは毎日使用されます。
私の質問は：
実際のデータに関連して、本番フェーズでパフォーマンスチューニングを行うことをお勧めしますか？
パフォーマンスのチューニングは、開発に不可欠な部分です。説明させてください。
開発でアプリケーション用のコードを開発しているときは、near to productionタイプのデータ（backup PRODデータ->負荷テスト環境での復元->すべての機密/ PIIデータをマスク）開発が完了したら、コードをテストできます。経験豊富なDBA（できれば開発の知識がある方）は、statistics ioおよび query plans は問題なく、クエリにはアンチパターンがありません。
私の会社には別の環境（パフォーマンステスト環境）があり、実際のPRODデータの近くで実際のユーザーワークロードをシミュレートし、読み込みが遅いページを追跡します（たとえば、 Miniなどのオープンソースツールを使用できます） Profiler ）および OpServer （有料のもの- SQLSentry が最適です）。
redgateのデータジェネレーター （無料ではない-有料！）などのツールがあります。これは、実際のテストデータを生成したいときに素晴らしい仕事をします。
データベースとその特定のストアドプロシージャのパフォーマンスを確認するために、どのプラグインまたはツールを使用しますか？
SQLサーバーツールへの私の答えをチェックして、クエリの最適化を確認してください
完全を期すために、ハードウェアを偽造することもできます（適切なテスト環境を取得する予算がない場合）- SMPマシンでのハードウェアNUMAの学習とデモのための偽造-BCDEdit
Remusの優れたブログ投稿- SQL Serverのパフォーマンスを分析する方法