私はアドバイスを求めてスタックを見回してきましたが、これを改善する最善の方法についてまだ100％確信が持てません。約 130K のレコードを格納する mysql INNODB 'product' テーブルがあります。その他の製品データなどには約 80 のフィールドがあり、各サプライヤー (コスト/ID/在庫) に対してサプライヤー在庫データ フィールド x 3 を追加した結果、さらに 35 ～ 40 の余分なフィールドができました。
xml/xls フィード用の loaddata または php スクリプトを使用して、サプライヤーごとに個別のテーブルにサプライヤー データ フィードを実行します。次に、単一のクエリを実行して、各テーブルの ID と一致する関連するサプライヤー テーブルの最新データで製品のコスト/在庫を更新します。このプロセスは、各サプライヤー フィード (現時点では約 15) に対して実行されます。場合によっては 1 日 1 回、場合によっては 2 回/3/4 回、フィードのサイズは数百から 1/3/20/30K までさまざまです。
次に、(サプライヤー データ フィードのインポート スケジュールが異なるため、1 日に数回) スクリプトを実行して、すべてのサプライヤーの在庫を (メインの製品テーブル データから) 比較し、その時点で在庫のある最も安いサプライヤーに基づいて価格を生成します。次に、どこかに在庫がある各アイテムについて、製品テーブル内の全体的な最良の製品価格を更新します。
update best price スクリプトは、どこかに在庫があるテーブルからすべてのレコードを選択し、計算を行ってから、各製品を個別に価格で更新します。私たちが抱えている問題は、この時間中に速度が低下することです。これは、1 分から 2 分程度の場合もありますが、サイトのトラフィックなどによっては 5/6 から最大 10 分かかる場合もあります。 -これは、実行ごとに最大 20/30,000 のレコードに対して行われている間、インデックス付けされます。
product テーブルはサイトで最もビジーなテーブルであり、更新が実行されると、CPU が 300/350% まで上昇することがわかります。最初に最善の選択肢が、保存された最良の価格と集計された株価を別のテーブルに分離し、インデックス作成/ロックの問題を回避するために製品データを引き出すときにこのテーブルを結合することであるか、または単にdb/webserver/email などを引き続き処理できる新しいサーバーに移行するか、専用の DB サーバーを実行する必要があります。
問題の再移行または新しい専用 db サーバーは、サーバーがこれらの遅い更新期間を超えて 10/20/30/40% の CPU でうまく対処するときのボスの停止点であるコストです。db サーバーを使用する場合、最も簡単なオプションは、新しいサーバーを取得し、そこから db を実行して、カスタム アプリ/メール サーバー/Web サイト アプリケーション ファイルなどの再インストールを節約することです。現在持っているサーバーよりもスペックの低いサーバーを使用するか、DBサーバーが2つのサーバーよりも優れたスペックであることを本当に考える必要がありますか?? どんな助けや一般的なアドバイスも大歓迎です!!! ありがとう。