0

多数の複雑なクエリがあり、その結果は MySQL ビューに保存されていました。問題は、MySQL ビューのパフォーマンスが低下することです。

ビューに入力されたのと同じデータを標準テーブルに入力する cron ジョブを設定しました。

DROP TABLE user_reports;
CREATE TABLE user_reports
  SELECT col1, col2, col3 FROM 
  /** COMPLEX QUERY **/
;

現在、cron が設定されたuser_reportsテーブルに対してクエリを実行すると、同等のビューと比較して、クエリにかかる時間はほぼ 10 分の 1 になります。

これは一般的なアプローチですか?明らかに、CRON ジョブが実行されるたびにサーバーに何らかの負荷がかかり、データがライブで利用できないことを意味します。

クエリにかかる 時間user_reports= 0.002 秒クエリにかかる時間= 0.018 秒
view_user_reports

つまり、実行に 0.018 秒かかるクエリは、ビューに格納するのではなく、アプリケーション コードから実行する必要があるのではないでしょうか? 私はそれがcron駆動の方法と同じようにスケーリングするとは思わないが.

4

2 に答える 2

1

ほとんどの場合、18ミリ秒のデータベース検索はパフォーマンスに悪影響を及ぼしません。そうである場合は、ある種のキャッシュを使用するのが一般的です。データを検索できるようにする必要があり、データがわずかに古い場合でも問題がない場合は、アプローチが適切です。

データを検索する必要がない場合は、キャッシュをメモリまたはファイルに直接保存できます。できれば、クライアントに配信するのと同じ形式で保存することをお勧めします。

于 2011-05-06T13:45:19.950 に答える
1

その結果はMySQLビューに保存されていました

まあ。MySQL ビューはデータを保存しません。

DROP TABLE user_reports;

CREATE TABLE user_reports

...何かがおかしい....

TRUNCATE TABLE user_reports;

?

私はそれがcron駆動の方法と同じようにスケーリングするとは思わない

cron ジョブのクエリの実行に時間がかからない場合に限ります。時間がかかる場合は、前処理された結果セットにデータを段階的に追加することを検討する必要があります。しかし、0.018 秒では、これは時期尚早の最適化です。

于 2011-05-06T14:35:20.537 に答える