10

プロジェクトのクエリキャッシュで多くの問題が発生しています。ローカル開発マシンと本番サーバーの両方で同じバージョンのMySQLのPerconaフレーバーを実行しています。これで、クエリキャッシュを有効にすると、ローカルマシンで優れた結果が得られます。キャッシュする必要のあるほとんどすべてのクエリは、事実上キャッシュされます。

現在、まったく同じクエリが本番サーバーにキャッシュされていません。すべてがまったく同じです。mysql変数、データベースコンテンツ、コードベース、ログインユーザー、..しかし、本番環境では、ほんの一握りのクエリのみがキャッシュされ、最も重要なクエリはすべてスキップされます。そして、私は理由を理解することはできません:-)

したがって、解決策を探して、トピックテーブルから最新の3つのトピックを選択するために使用される次のクエリを使用しています（これは最も「重い」クエリであり、絶対にキャッシュしたいクエリです！）

SELECT `topic`.* FROM `topics` AS `topic` 
LEFT OUTER  JOIN `topics` AS `topic_helper` 
 ON (`topic`.`id` = `topic_helper`.`id` 
      AND `topic_helper`.`created_on` < `topic`.`created_on`) 
GROUP BY `topic`.`id` HAVING COUNT(*) < 3 
ORDER BY `topic`.`created_on` DESC;

それで、最初に、SHOW VARIABLES LIKE '%query_cache%私に同じ結果を与えてください、両方とも生産時とローカルです：

+------------------------------+----------+
| Variable_name                | Value    |
+------------------------------+----------+
| have_query_cache             | YES      |
| query_cache_limit            | 1048576  |
| query_cache_min_res_unit     | 4096     |
| query_cache_size             | 10485760 |
| query_cache_strip_comments   | OFF      |
| query_cache_type             | ON       |
| query_cache_wlock_invalidate | OFF      |
+------------------------------+----------+

上記のクエリを実行すると、最初の実行後にローカルにキャッシュされますSHOW PROFILE。これは、トレースの終わり近くにあることを明確に示しています。

| Waiting for query cache lock   | 0.000001 |
| Waiting on query cache mutex   | 0.000001 |
| freeing items                  | 0.000000 |
| storing result in query cache  | 0.000002 |
| logging slow query             | 0.000001 |
| cleaning up                    | 0.000006 |
+--------------------------------+----------+

2番目の呼び出しは、期待どおりにキャッシュからクエリを返します。

本番サーバーでは、このクエリを実行してもキャッシュに保存されることはありません。結果セットはまったく同じであり、クエリキャッシュを無効にするステートメントが使用されていないことは明らかです（http://dev.mysql.com/doc/refman/5.1/en/query-cache-operationのマニュアルによると） .html-上記のクエリは、キャッシュするための要件に準拠していると確信しています。）

完全を期すためSHOW PROFILEに、本番サーバーでの同じクエリの完全な出力は、ここに貼り付けられます：http: //pastebin.com/7Jm5rmVd

また、構成は両方のサーバーでまったく同じですが、私のローカルバージョンは5.5.27であり、本番5.5.17-55のものよりもわずかに新しいことに注意してください。これが問題なのかもしれません..？

ローカルサーバーと本番サーバーの両方からの完全な出力を比較して、SHOW VARIABLES;不足しているものがないかどうかを確認しましたが、システムのタイムゾーンとログファイルへのパスなどを除いて何も変わりません。

では、次にどこを探すべきか知っている人はいますか？または、これを引き起こしている可能性のある手がかりはありますか？

4

1 に答える 1

1

ここではPerconaサーバーを頻繁に使用し、コミュニティMySQLも使用しています。

クエリキャッシュは強力であり、非常に複雑です。MySQLが実行できる最悪のことは、古いキャッシュデータを返すことです。

MySQLはクエリだけでなく、データベースデータもキャッシュし、パフォーマンスを向上させるためにインデックスを使用します。

クエリキャッシュを無効にする可能性のあるものはすべて無効にします。

経験則として、キャッシュされているかどうかにあまり焦点を当てていません... MySQLがインテリジェントに動作することを信頼しています-何らかの理由で何かをキャッシュすべきではないと判断した場合、キャッシュされません。ただし、私たちが行うことは、クエリが可能な限り効率的かつ単純であることを確認することです。

私がこれを言うかもしれない-あなたの例のクエリが「あなたの最もよく使われるものの1つ」であるならば、あなたはクエリキャッシュに関係なく深刻なスケーラビリティの問題にぶつかるだろうと思います。サーバーがビジーになると、足のない犬のように走ります！

ペーストビンのエントリによると、おそらく外部結合（またはGROUP BY）が原因で、少なくとも1つの一時テーブルが作成されています。

私はすべて正規化を求めていますが、パフォーマンスが代替ルートを必要とする場合があります。

そのデータの一部を、ある種のルックアップ/サマリーテーブルに自分でキャッシュすることはできませんか？トリガーはここであなたの友達になることができます:)

于 2013-03-15T11:05:20.920 に答える