タグ付けされた質問 「performance」

32 GBのRAMと4つのコア、60〜80の同時接続でSQL Server 2012 SP3を実行し、主にアドホックなワークロードで、SQL Serverプロセス（CPU）が急上昇し、予測できない時間に1日に1回または2回急上昇し続けています。スパイクの根本的な原因の特定に取り組んでいます。それまでの間、最大メモリ設定の変更（アップまたはダウン）が、CPUの負荷を通常に戻す唯一の方法であることがわかりました。 ログを確認し、StackExchange（https://dba.stackexchange.com/a/183276）を検索すると、最大メモリ設定を変更することにより、プランキャッシュがフラッシュされていることがわかります。ただし、DBCC FREESYSTEMCACHE（ 'SQL Plans'）を介してプランキャッシュをフラッシュすると、CPU負荷は通常に戻りません。 最大メモリ設定を変更すると、天候に関係なく問題が解決するため、問題は最大サーバーメモリ設定に直接関連しているようには見えません。そのため、メモリ設定を変更する他のことを理解し、その情報を使用してCPUスパイクの根本的な原因を特定しようとしています。

8 sql-server  performance 

SO、外部ブログ投稿、マニュアルに関するいくつかの質問をすでに読んだことがある SO：Pgのパーティションテーブルへの外部キー制約 dba.SE：PgのパーティションテーブルへのFKのさまざまな処理方法 マニュアル：継承 マニュアル：パーティショニング 手動：制約トリガー ブログ：継承によるPostgresモデリング それでも、自分のケースを考慮してパーティション分割を行うべきかどうか疑問に思っています。 ケース-簡略化 顧客データの保存。下記の表の名前はすべて、わかりやすくするために作成されています。 顧客によって識別可能で非物理的な存在であるオブジェクト、およびオンデマンドで顧客にオブジェクトを送り返す必要がある場合にオブジェクトが実際に格納される物理オブジェクト、または他の方法でオブジェクトを処理する。それらは多対多の関係でマッピングされます。objects_nonphysical、objects_physical、objects_mapping_table。 2番目の多対多の関係は、これらの非物理オブジェクトとそのメトリックの間です。いくつかのメトリックにバインドされているオブジェクトがあります。metrics、metrics_objects_nonphysical 非物理オブジェクトと物理オブジェクトの両方に、子と親の関係である階層テーブルがあります。objects_nonphysical_hierarchy、objects_physical_hierarchy 各顧客のニーズと要件に応じて、物理オブジェクトに関するデータを提供することも、ゼロから作成する必要がある場合もあります。基本的に、私がする必要があるのは： 高速のための社内体制の維持INSERTおよびSELECTマッピングが場所を取るために起こっているのはここであるため、ステートメントを。 外部顧客が非物理オブジェクトを表示および操作できるようにシステムを維持します -データの高速検索。ステートメントの効率に対する強いニーズSELECT -このデータは、多くの顧客がいつでも検索できるようになっています。 私の配慮 データにアクセスし、データを表示して操作する顧客がいる可能性がありますが、それは、データを取得したり、データを処理している請負業者である必要はありません。 これにより、システムにテーブルパーティション分割を導入し、どのパーティションデータが該当するか（請負業者のパーティション分割）を常に把握していることを考慮し、次に、顧客のパーティション分割が必要な外部顧客向けのメインテナンスシステムに進みました。（これは、自動化ツールと一連のルールを使用して顧客の方法でデータを書き換えるのを遅らせるため、顧客ごとにテーブルごとに1つのパーティションのみをスキャンします。 データ量 特に新しい顧客のオブジェクトとメトリックをインポートする場合、私のデータは常に増加します。システムに到着する新しいデータのペースは、長期的に見て現時点では予測できません。誰が次の顧客になるかがわからない場合、実際に測定する方法はありません。現在、2つの顧客があり、各テーブルのすべての顧客に対して100万行が多かれ少なかれあります。しかし、将来的には、新規顧客の数が1,000万人になると予測しています行程度になるています。 ご質問 これらの質問はすべて互いに関連しています。 ここでパーティショニングを本当に考慮すべきですか、それとも過剰ですか？私は常に正確に1つをスキャンしているので、それは役に立つと考えていますパーティションを。 パーティショニングがFK最適な方法である場合、自分のニーズを考慮して最も効果的に制約を適用するにはどうすればよいですか？私は行くべきconstraint triggersですか、それとも内部システムのアプリケーション層に保つべきですか、それとも他の方法でしょうか？ パーティショニングがうまくいかない場合、何に飛び込むべきですか？ 十分なデータが提供されていない場合は、下のコメントでお知らせください。

8 postgresql  performance  partitioning  postgresql-9.4 

テキスト文書から抽出されたデータを含むテーブルがあります。データは、"CONTENT"GINを使用してこのインデックスを作成したという名前の列に保存されます。 CREATE INDEX "File_contentIndex" ON "File" USING gin (setweight(to_tsvector('english'::regconfig , COALESCE("CONTENT", ''::character varying)::text), 'C'::"char")); 次のクエリを使用して、テーブルで全文検索を実行します。 SELECT "ITEMID", ts_rank(setweight(to_tsvector('english', coalesce("CONTENT",'')), 'C') , plainto_tsquery('english', 'searchTerm')) AS "RANK" FROM "File" WHERE setweight(to_tsvector('english', coalesce("CONTENT",'')), 'C') @@ plainto_tsquery('english', 'searchTerm') ORDER BY "RANK" DESC LIMIT 5; ファイルテーブルには250 000行が含まれ、各"CONTENT"エントリは1つのランダムな単語とすべての行で同じテキスト文字列で構成されます。 ここで、ランダムな単語（テーブル全体で1ヒット）を検索すると、クエリは非常に高速に実行されます（<100ミリ秒）。ただし、すべての行にある単語を検索すると、クエリの実行が非常に遅くなります（10分以上）。 EXPLAIN ANALYZEは、1ヒット検索の場合、ビットマップインデックススキャンとそれに続くビットマップヒープスキャンが実行されることを示しています。遅い検索では、代わりにSeq Scanが実行されますが、これは非常に時間がかかっています。 もちろん、すべての行に同じデータを含めることは現実的ではありません。しかし、ユーザーがアップロードしたテキストドキュメントやユーザーが実行する検索を制御できないため、同様のシナリオが発生する可能性があります（DBで非常に出現頻度の高い用語で検索）。このようなシナリオで検索クエリのパフォーマンスを向上させるにはどうすればよいですか？ PostgreSQL 9.3.4の実行 クエリプランEXPLAIN …

8 postgresql  performance  index  postgresql-9.3  full-text-search 

私は、16のCPUを搭載したサーバーで、a max degree of parallelismが8、max worker threads設定が0に設定されています。 所定の時間、私の信号待機は20％でしたが、その間の私のOS CPU使用率は25％を超えることはありませんでした。誰かが私の信号待機が非常に高かった理由を説明できますか？ 私のベンダーはクラス最高のスコアリングシステムを使用しており、信号待機が10％以下であると予想します。（CPUを追加せずに）これを修正するにはどうすればよいですか？ NUMAノードごとに8個を超えるCPU はないため、トレースフラグ8048は適用されません。 最大のインスタンス待機はCXPACKET（70％）、次にPREEMPTIVE_OS_PIPEOPS（20％） cost threshold for parallelism50に設定されています。上げる必要がありますか？何に？ これは、SQL Server専用の物理マシン（VMではない）です。 監視ツールを使用して、最も頻繁に実行されるクエリとプロシージャを特定しています。高CPU、高I / O、または高継続時間を確認しますか？通常、アプリはI / Oを集中的に使用するため、高いI / Oを調整します。しかし、問題はシグナル待機であるため、CPU使用率が高いことを確認する必要がありますか？ アプリが追加のスレッドを必要とするウェアハウススタイルのクエリを実行するため、4 に下げるというMax Vernonの推奨を回避したいと思ってMAXDOPいました。

8 sql-server  performance 

概要と比較可能なデータを取得するための私の現在のタスクは、さまざまな生産的なSQL Serverインスタンスに関するいくつかの数値を取得するためのパフォーマンスベースラインを作成することです。 私の考えは： 複数のDMVを使用したい プロファイラートレース（実行計画を含む）を含めたい perfmonデータを含めたい したがって、私が達成しようとしているのは、開始可能および停止可能（スケジュール可能でもあります）の一般的なパフォーマンスモニタリングです。 進行中のパフォーマンス最適化タスクの成功を識別するために必要なすべての情報 長期的な進捗状況を視覚化するのに役立つ、いくつかの集約された単純な図..特に 管理用;-) 個々のキューの変更とインデックス最適化タスクによる改善を比較するためのプロファイラートレース内の再実行可能な実行プラン パフォーマンスベースラインの作成について説明している情報がいくつか見つかりました。それらのほとんどは、非常に複雑であるか、目的のパフォーマンスインジケーターの1つ（主にパフォーマンスデータ）にのみ焦点を当てています。 最も一致するサンプル/説明は次のとおりです。SQLServerのパフォーマンスベースラインの作成 質問は： この種のパフォーマンスモニターをすばやく実行可能な方法で作成した経験がある人はいますか？

8 sql-server  performance  monitoring 

使用時間を追跡する分析システムのスキーマに取り組んでいます。特定の日付範囲の合計使用時間を確認する必要があります。 簡単な例を挙げると、このタイプのクエリは頻繁に実行されます。 select sum(diff_ms) from writetest_table where time_on > ("2015-07-13 15:11:56"); 通常、このクエリは、データが密集しているテーブルで約7秒かかります。約3,500万行、Amazon RDS（db.m3.xlarge）で実行されているMySQLのMyISAMがあります。 WHERE句を削除すると、クエリの所要時間がわずか4秒になり、2番目の句（time_off> XXX）を追加すると、さらに1.5秒追加され、クエリ時間が8.5秒になります。 私はこれらのタイプのクエリが一般的に行われることを知っているので、それらをより速く、理想的には5秒未満に最適化したいと思います。 私はtime_onにインデックスを追加することから始めましたが、WHERE "="クエリは大幅に高速化しましたが、 ">"クエリには影響がありませんでした。WHERE ">"または "<"クエリを高速化するインデックスを作成する方法はありますか？ または、このタイプのクエリのパフォーマンスについて他に提案がある場合は、お知らせください。 注：「diff_ms」フィールドを非正規化ステップとして使用しています（time_off-time_onと同じです）。これにより、集約のパフォーマンスが約30％から40％向上します。 私はこのコマンドでインデックスを作成しています： ALTER TABLE writetest_table ADD INDEX time_on (time_on) USING BTREE; （「time_on>」を使用して）元のクエリで「explain」を実行すると、time_onは「possible_key」であり、select_typeは「SIMPLE」です。「追加」の列は「使用場所」を示し、「タイプ」は「すべて」です。インデックスが追加された後、テーブルは「time_on」が「MUL」キータイプであることを示しています。これは、同じ時間が2回存在する可能性があるため、正しいように見えます。 これがテーブルスキーマです： CREATE TABLE `writetest_table` ( `id` int(11) unsigned NOT NULL AUTO_INCREMENT, `sessionID` int(11) DEFAULT NULL, `time_on` …

8 mysql  performance  index  select  myisam 

ベンダーとの長期にわたる問題のトラブルシューティングを行っています。彼らのソフトウェアはフリーズして、週に1〜2回作業を停止する傾向があり、私たちの操作に大きな混乱を引き起こしています。多くのGBのログとDBのバックアップを送信しても、原因を特定できませんでした。最近、彼らは問題が私たちのメンテナンスに関するものであり、おそらくソフトウェアに関するものではないことを示唆し始めています（問題が発生したときに長時間実行されているクエリ、CPU / RAM / IOプレッシャー、またはデッドロックさえないにもかかわらず）。特に彼らは私たちのインデックスが問題であると言っています。 彼らが使用するのにお気に入りのツールはDBCC showcontigですが、これはMSによって廃止されると主張しています。彼らは特にスキャン密度と範囲の断片化にこだわっています。言い訳を取り除くために、<90％のスキャン密度または> 10％の断片化でインデックスを再構築する積極的な夜間メンテナンスを行いました。これにより、スキャン密度トレインからそれらをある程度放棄しましたが、エクステントの断片化に固定されたままです。DBCC showcontigは、数時間前に再構築されたインデックスでも、高度な断片化を示します。以下は、「可能性のある問題」として指摘されたテーブルのdbcc_showcontigおよびsys.dm_db_index_physical_statsの結果です。 DBCC SHOWCONTIG スキャンしたページ................................：1222108 スキャンされた範囲..............................：152964 エクステントスイッチ..............................：180904 平均 エクステントごとのページ..................................：8.0 スキャン密度[ベストカウント：実際のカウント] .......：84.44％[152764：180905] 論理スキャンの断片化..................：3.24％ エクステントスキャンの断片化...................：35.97％ 平均 ページあたりの空きバイト..................................：692.5 平均 ページ密度（フル）.....................：91.44％ sys.dm_db_index_physical_stats index_type_desc alloc_unit_type_desc Avg_fragmentation_in_percent page_count CLUSTERED INDEX IN_ROW_DATA 3.236803129 1222070 NONCLUSTERED INDEX IN_ROW_DATA 0.680074642 48230 NONCLUSTERED INDEX IN_ROW_DATA 0.093237195 48264 NONCLUSTERED INDEX IN_ROW_DATA 0.03315856 48253 NONCLUSTERED …

8 sql-server  performance  index 

BLOB（タイプimage）を複製するためのマージパブリケーションがあり、私のデータサイズに対して非常に高いtempdbディスクI / Oを取得しました。パブリケーションはダウンロード専用であり、フィルターはありません。 高いディスクI / Oは同期によって引き起こされ（サブスクライバーが同期していない場合はすべて問題ありません）、サブスクライバーの数と強く相関しています。同期の間にパブリッシャーでデータが変更されていない場合でも発生します。 複製されたテーブルのサイズ：7MB（行の総数は約100） tempdb I / O：書き込み（ログおよびデータファイル）の場合、最大30 MB /秒 サブスクライバーの数：100をわずかに超え、それぞれが30分ごとに（ほぼ均等に）同期しています。 保存期間を14日に設定 パブリッシャーではSQL Server 2008を、サブスクライバーではSQL Server 2005-2008R2を使用します。すべてのサブスクライバーはWeb同期を使用します。 さらに、サブスクライバーでの同期には多くの時間がかかり、replmerg.log次のように複数回発生します。 DatabaseReconciler, 2015/04/21 12:13:40.348, 3604, 25088, S2, INFO: [WEBSYNC_PROTOCOL] Sending client ReconcilerPhase WebSyncReconcilerPhase_RegularDownload DatabaseReconciler, 2015/04/21 12:13:47.063, 3604, 25194, S2, INFO: [WEBSYNC_PROTOCOL] Received server ReconcilerPhase WebSyncReconcilerPhase_LastRegularDownload @stream_blob_columns効果なしで設定のオンとオフを試みた。 質問がある：それは加入者にこれらのブロブを送信するためにマージレプリケーションを使用することをお勧めしますか？tempdbの問題のない大量のデータを含む他のパブリケーション（BLOB列はありません）があります。それはSQL Serverの欠陥ですか、それとも不適切な設定ですか？ パブリッシャーとディストリビューターは同じインスタンス、SQL Server …

8 sql-server  performance  merge-replication 

以前にこれと似たような質問をしましたが、以前はバックアップを共有の場所に移動することについて質問していました。今回は気になります。共有ドライブにデータベースを復元する場合、そのサーバーまたはSQL Serverを実行しているサーバーだけでIFIを有効にする必要がありますか？ 私が尋ねる理由は、かなり大きなデータベースを復元していて、過去2、3時間は100％で停止してしまったためです。の待機タイプsp_whoisactiveは次のとおりです。 (28472716ms) `PREEMPTIVE_OS_WRITEFILEGATHER. 私が見たのは、IFIがオンになっていないときだけですが、SQL Serverでは有効になっていますが、共有ドライブサーバーでは有効になっていません。

8 sql-server  performance  restore 

私たちのサイトには、統計情報のためのいくつかの大きくて単純な（INT、INT、DATE）テーブルがあります。各テーブルには最大300,000,000行があり、毎日大きくなります。 ホスティングプロバイダーは、テーブルを分割またはパーティション分割することを提案しており、この推奨事項を他の場所で何度も見ました。 しかしながら... 私はこのアドバイスをSQL Serverの最大容量 -524,272テラバイトのデータベースサイズと調整し、テーブルの行は「利用可能なストレージ」によってのみ制限されます。 これらの数値に基づいて、上記の表は数百万行（10の303乗）を簡単に持つことができます。 ああ、あなたは言うかもしれませんが、能力とパフォーマンスには違いがあります。 しかし、SQL Serverのパフォーマンスに関するほぼすべての質問で、答えは「テーブルの設計とクエリの設計によって異なります」です。 それが私がこの質問をしている理由です。テーブルの設計はこれほど単純ではありません。インデックス付きIDフィールドに基づく単純なcount（*）操作であるクエリもできません。

8 sql-server  performance 

実稼働環境にはいくつかのdbサーバーがあり、そのうち4つはハードウェア構成が非常に似ています。Dell PowerEdge R620、唯一の違いは、最新の2つ（3か月前に購入および構成されたもの）にRAIDコントローラーv710、256GB RAM、およびCPUが2つの物理Xeon E5-2680 2.80GHzであることです。古いもの（約1年前に購入および構成されたもの）には、RAIDコントローラーv700、128GB RAMがあり、2つの物理Xeon E5-2690 2.90GHzで実行されています。BIOSの更新、すべてのドライバーの最新バージョンへの更新など。実行中のすべてのSQL Server 2008R2 Enterprise（SP1）が最新のCUおよびWindows 2012R2 Standardに更新されました。どちらも200 GB SSD x5 RAID10で動作します。それぞれで実行されているデータベースは1つだけで、SSISパッケージを呼び出すジョブを使用して同期されます。私たちのシステム管理者は、ハードウェアやネットワークの設定ミスや失敗がないことを確認するために、多くのパフォーマンスとストレステストを実行しました。予想通り、最新のものはより良いパフォーマンス結果を示しています。ここまでは順調ですね。 私たちが抱えている問題は、Kibanaの画面キャプチャーで確認できます。黄色とオレンジは2つの新しいサーバー（テーブルでは6、7）で、他のすべてのサーバーの下にあります。これらの2つの新しいサーバーの応答時間が遅いことが完全にわかります。それだけでなく、これらの2つのサーバーの負荷も、2つの古いサーバーよりもわずかに少なくなっています（表の淡い青色と濃い青色の線-4,5）。 パフォーマンスカウンターに関する情報を収集するいくつかの監視スクリプトを用意します。DMVと3番目の監視ツールで可能な限り掘り下げたので、私は多くの情報を手元に持っています。しかし、この遅い応答時間に対する答えを見つけることができないため、ここで見逃していることがあるはずです。 最新の2台のサーバーはRAMの使用量が少ないですが、他の古いサーバーと比較すると、負荷が低いため、それは予想通りです。 | Server Name| Mem_MB | Mem_GB | Server_RAM_GB | SQL_max_mem_GB| SQL_min_mem_GB | |------------|--------|--------------|---------------|---------------|----------------| | 4 | 41108 | 40.145263671 | 128 | 120 | 16 | | 5 | …

8 sql-server-2008-r2  performance  configuration  performance-tuning  performance-testing 

MySQLサーバーをテストサーバーと本番サーバーの2つの異なるマシンにインストールしました。どちらもWindowsであり、ウェブアプリケーションで使用されます。 問題は、いくつかのクエリを実行すると、2つのマシン間でパフォーマンスが大幅に異なることです（本番サーバーの方が低速です）。両方のサーバーのMySQLバージョンは同じです。構成ファイルも同じです（唯一の違いは、データのパスと、運用サーバーがエラー以外のログを記録しないことです）。私が話しているパフォーマンスの違いは3桁または4桁大きくなっています（たとえば、テストサーバーでのクエリは0.2秒で実行されますが、運用サーバーでは84秒で実行されます）。 問題のクエリは、 "WHERE [...] IN [...]"を含む句を多用しています。これは、通常非常に遅く、JOINに置き換える必要があることを理解しています。ただし、使用しているMySQLのバージョンは5.6.19であり、これらのクエリは自動的に最適化されます。そのため、テストサーバーではクエリが高速に実行されます（変更できないプログラムの一部であるため、手動で最適化することはできません）とにかく）。 先ほど述べたように、MySQLのインストールと構成は同じであるため、問題がどこにあるのかはまったくわかりません。一方では、プログラムとDBが同じであるため、なんらかの構成上の問題である必要があると思いますが、一方で、構成が同一であるため、これは意味がありません。 サーバー上のデータ： テストサーバー： Intel Core 2 Quad Q9400 @ 2.66GHz 8GB RAM Windows Server 2008 R2スタンダード 本番サーバー： Intel Xeon E5530 @ 2.40GHz 5GB RAM Windows Server 2012 R2スタンダード 編集：重要なことを言うのを忘れていました。「問題の」クエリとは別に「WHERE ... IN」句を使用するクエリが実行されています。これらは両方のマシンで高速に実行され、MySQLによって正しく最適化されていることを示唆しています。他のクエリが最適化されていないときに最適化されているクエリがあるのは不思議です。これが実際の問題であるかどうかは不明です。 編集＃2：両方のサーバーの構成ファイルは次のとおりです：http : //pastebin.ca/2834906 編集＃3：遅いクエリの1つ のEXPLAINは次のとおりです。https：//mariadb.org/ea/v36zj EXPLAINは、テストと製品の両方でまったく同じです。クエリ自体はこちらです：http : //pastebin.com/VXgBxXmtこれはオートフォーマッタでフォーマットされているため、あまり明確ではありません。ご覧のとおり、は非常に長く複雑です。これは手動で生成されたものではなく、いくつかの機能を備えた標準SQLの方言を使用するソフトウェアによってさらに自動的に生成されます。 また、詳細情報：本番サーバーのデータを減らし、使用されないDBの古いデータのほとんどを削除することで、一時的に問題にパッチを適用しました。もちろん古いデータも必要なので、これは解決策ではありません。将来的には問題になるでしょう。DBはそれほど大きくありません。完全なDBは1308MBで、現在生産中の縮小バージョンは332MBです。 更新：解決しましたか？ 私は問題を解決したと思います。本番サーバーが実際に使用されているため、まだテストしていませんが、考えられる問題は、182Mに設定されたパラメーター "innodb_buffer_pool_size"でした。実際には、構成ファイルの行は次を示しています：innodb_buffer_pool_size …

8 mysql  performance  windows 

SQL Serverの削除動作に関する追加の洞察/推論を取得したいと思います。1800 GBを超えるかなり大きなデータベースがあります。 数百万行の非常に浅いテーブル（少数の整数列のみ）があります。これらの浅いテーブルから10,000の行を削除する場合、削除クエリは一般に非常に高速です（多くても数秒）。 また、image平均100 KBの画像を保存するタイプのフィールドを持つテーブルもあります。このテーブルから数千行しか削除しない場合、1分以上かかります。 違いは明らかですが（サイズの点ではるかに多くのデータが削除されます）、SQL Server内で何が起こるかについてもっと知りたいと思っています。後者の削除が非常に遅くなることをよりよく理解できるように。 誰かが光を当ててくれますか？

8 sql-server  performance 

何度も実行するのに長い時間がかかるMyISAMテーブルで特に厄介なクエリを見ると、MySQLはかなり奇妙なI / Oパターンを公開しているように見えることに気づきました。 I / Oの量（たとえば、テーブルスキャンの場合、または結果としてキャッシュが空にecho 3 > /proc/sys/vm/drop_cachesなるため、最初にインデックスをディスクからロードする必要がある場合）、基礎となるブロックデバイスのキューサイズは値1に近く、パフォーマンスは非常に低いわずか4〜5 MB /秒： root@mysql-test:~# iostat -xdm 5 /dev/sda Linux 3.2.0-40-generic (mysql-test) 04/30/2014 _x86_64_ (4 CPU) Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util sda 0.14 24.82 18.26 88.79 0.75 4.61 102.56 2.83 26.39 19.29 27.85 2.46 …

8 mysql  performance  myisam 

私はプログラマーで、次のような大きなテーブルを扱っています。 UpdateTime, PK, datetime, notnull Name, PK, char(14), notnull TheData, float にクラスター化インデックスがあります Name, UpdateTime 私は何が速くなるべきか疑問に思っていました： SELECT MAX(UpdateTime) FROM [MyTable] または SELECT MAX([UpdateTime]) AS value from ( SELECT [UpdateTime] FROM [MyTable] group by [UpdateTime] ) as t このテーブルへの挿入は、同じ日付の 50,000行のチャンクです。したがって、グループ化することでMAX計算が容易になると考えました。 最大150,000行を見つけようとする代わりに、3行にグループ化すると、計算MAXが速くなりますか？私の仮定は正しいですか、グループ化もコストがかかりますか？

8 sql-server  performance  query-performance  group-by