データベースから製品を照会し、30 項目のページに表示するページがあります。次のページに移動すると、アプリケーションは DB を再クエリし、ページ番号を表示します。2など。
このデータベースの再クエリを回避するにはどうすればよいですか? 結果をどこかに保存できますか？クエリあたり 1,500 ～ 2,000 行で、400 ～ 450 人のユーザーがオンラインの場合、専用サーバーは 100% の CPU 容量で実行されます。
質問する
272 次
2 に答える
0
前述したように、私が解決策を求めていた主な理由は、CPU の過負荷を避けることでした。オンラインのユーザーが 500 ～ 600 人しかいない状態で、サーバーが 100% 混雑するのは不自然に思えました。MyISAM テーブルで動作する optimize table MySQL コマンドを発見し、問題を完全に解決しました。コマンドを実行した直後、CPU 使用率は 10 ～ 12% に下がりました。
そのため、CPU を過負荷にする MySQL アプリケーションを実行しているユーザーが他にいる場合は、最初に Optimize Table コマンドと、ここで説明されているその他のメンテナンス タスクを試してくださいhttp://dev.mysql.com/doc/refman/5.5/en/optimize -table.html
于 2013-04-28T14:04:51.900 に答える
0
「カタログ」全体を (アプリケーション レベルのストレージに) プリロードし、SQL ですべての結果を返し、インデックスのみを (各セッションに) 格納するのに十分なメモリがありますか。このようなもの: アプリケーションの開始時: 読み取り専用のアプリケーション レベル キャッシュを作成する 検索時: SQL はすべての結果を返します (SQL を実行する必要があると想定しているため、ビジネス条件を確認できます) 結果時: アプリケーション キャッシュにマップされるインデックスのリストを作成します表示ページ: アプリケーション キャッシュから適切な範囲を読み取り、表示します。
十分なメモリがない場合は、「結果」テーブルが最適化を提供する可能性があります。セッションごとに、クエリ結果全体を「フラット化された」テーブルにキャッシュして、潜在的に高価な (ビジネス ロジックが重い) 製品を回避します。クエリ。クエリがいつ変更されたかを注意深く検出する必要があるため、キャッシュを破棄できます。また、古い期限切れの検索をクリーンアップするためのサーバー側のロジックも必要です。
于 2013-03-25T05:50:49.847 に答える