40000個の製品を含むテーブルの断片化がパフォーマンスに影響を与える可能性
データベース管理は私の得意分野ではないので、いくつか質問があります。
これはすべて、私が見ているWebサイトのパフォーマンスに関連しており、かなりの時間を調査/診断に費やしてきました。
- テストサイトとライブサイトの2つのサイトがあります。
テストサイトとは対照的に、ライブサイトではページの読み込み時間がはるかに長いことに気付きました。
テストサイトの仕様は非常に低い-14GBのVPS 2仮想プロセッサRAMおよび同じVPSで実行されているSQL + Webサイト
ライブウェブサイトの仕様は、すべて8つの仮想プロセッサと16GB RAMを備えた4つの専用サーバーです。
ライブサイトでは、16個の仮想プロセッサと112GBのRAMを備えたSQL用に別の専用サーバーを使用します
Webサイトの平均同時ユーザー数は常に平均120人ですが、70から150まで変動する可能性があり、メールキャンペーンを送信すると、400に達する可能性があります。400に達すると、ユーザーのアクションによっては、CPUが100％に達する可能性があります。ウェブサイトでやっているのですが、RAMと同じぐらいうまくいきます。
実際のウェブサイトは実際にはテストウェブサイトよりもパフォーマンスが高いと思いますが、これは事実ではありません。私はコードを調べましたが、それはデータベースが原因であると強く信じています。バックアップ中のライブWebサイトのデータベースサイズは50GBを超え、テストサイトは4GBです。
両方のデータベースはかなり断片化されており、断片化がパフォーマンスにどの程度影響する可能性があるのでしょうか。
また、ライブWebサイトはテストサイトより何倍も大きいため、高い断片化はテストサイトよりもライブサイトのパフォーマンスに大きな影響を与えますか？
これは、productsテーブルのインデックスの1つのキャプチャです。 
インデックスの再構築/更新に関するいくつかのヒントは何ですか？.
インデックスを再構築/更新している間、誰もテーブルを操作できないように、Webサイトをメンテナンスモードにする必要がありますか？
12個のインデックスと40000個の製品を含むテーブルでどれくらい時間がかかりますか？
ありがとう
あなたが提供したデータに基づいて-
合計67ページです。このような小さなテーブルのインデックスの断片化はパフォーマンスに影響しません。私はあなたが言及したテーブルのインデックスの断片化について心配しません。
SQLサーバーがより良いクエリプランを生成できるように、テーブル統計を更新する必要があります。
トラブルシューティングを開始する
読み取り： SQL Serverの断片化に関する心配をやめる
インデックスは、使用（時間）の過程でフラグメントにバインドされます。重要なのは、それがパフォーマンスに影響を与えているかどうかです。
通常、page_count <500のインデックスについては気にしません。（私たちのチームと同じですが）、特定のpage_countには厳格な規則はありません。以前のショップでは、Olaスクリプトに1000の制限を設定していました。ページ数。しかし、そうです。インデックスにpage_count = 67が指定されている場合、断片化は常に高い側にあります。
現在のpage_countでの断片化について心配する必要はありません。
以下のPaul Randalのブログ投稿をご覧ください。
テストサーバーとライブサーバーの主な違いはConcurrencyです。
テストサーバーでConcurrencyテストを実行していません。
Concurrencyは、Liveサイトが遅くなる主な理由の1つです。
あなたが接続文字列で書いたもののように、どのようなコードがフロントエンドアプリケーションで書かれています。 connection poolと同様に、各トランザクションの後でconnectionが適切にcloseであるかどうか。これが、速度低下の主な理由です。
次に、フロントエンドコードの他の部分。
SPに書き込まれるクエリ。同時ユーザーによるdeadlockの問題かどうか。
同時ユーザーが同じ行のセットを更新しようとする状況はありますか？レース状態をどのように処理しますか？
12 indexレコードのみの単一のテーブルに40000があるのはなぜですか？
すべてのインデックスとともにテーブル構造をスローしてください。