web-dev-qa-db-ja.com

InnoDBを使用してMySQLクエリキャッシュを有効にするかどうかを決定する方法

InnoDBテーブルのみを使用するサーバーで、MySQLクエリキャッシュを有効/無効にする決定をどのように行う必要がありますか。たとえば、キャッシュが有効になっている場合、出力は次のようになります。

SHOW STATUS LIKE 'Qcache%';

決定するために解釈されますか？または、他のクエリ/プロファイリングを実行して詳細情報を取得し、それらをどのように解釈すべきですか？有効にする場合、そのサイズはどのように決定する必要がありますか？ MySQL 5.6を使用して、Amazon RDSにいます。結局、約250の個別のデータベースになり、合計で約200 GBになります。

mysqlinnodbamazon-rdsaws
3
Michal Charemza

以前の投稿でこれについて話しました

InnoDB内部は、クエリキャッシュエントリの無効化を細かく管理するため、クエリキャッシュに対して非常に実践的なアプローチを持っています。 MySQL 4.xでは、クエリキャッシュはInnoDBのためにデフォルトで無効にされていました。 MySQL 5.xでは、トスアップになる可能性があります。 @akuzminskyからのコメントは、InnoDBを中心とした地域の問題を示しています。

Amazon RDSを使用しているという事実を考えると、次の課題が見つかります

  • 一部のInnoDB設定の変更は面倒な場合があります
  • 一部のInnoDB設定は変更できません
  • InnoDBのチューニングの側面にはRDSによる制限があります

私はすべての推測作業を取り除き、クエリキャッシュを無効のままにします。 （@akuzminskyの2番目のコメントで提案されているように）バッファープールサイズが大きい場合は、より大きなサーバーモデル（$$$ Cha-Ching $$$）に移行する必要があります。サーバーモデルのバッファプールサイズは次のとおりです

MODEL      max_connections innodb_buffer_pool_size
---------  --------------- -----------------------
t1.micro   34                326107136 (  311M)
m1-small   125              1179648000 ( 1125M,  1.097G)
m1-large   623              5882511360 ( 5610M,  5.479G)
m1-xlarge  1263            11922309120 (11370M, 11.103G)
m2-xlarge  1441            13605273600 (12975M, 12.671G)
m2-2xlarge 2900            27367833600 (26100M, 25.488G)
m2-4xlarge 5816            54892953600 (52350M, 51.123G)
4
RolandoMySQLDBA

_SHOW GLOBAL STATUS;_

次に、これらを計算します（MyISAMとInnoDBのどちらを使用していても）。

  • _Qcache_lowmem_prunes / Uptime_-QCがプルーニングされる頻度-15 /秒を超えると、QCをオンにするとオーバーヘッドが多くなります。
  • _Qcache_not_cached / Uptime_-キャッシュ試行が失敗しました（1秒あたり）。 > 40はおそらく悪い。
  • Qcache_not_cached / (Qcache_hits + Com_select + Qcache_not_cached)-QCにキャッシュされないSELECTsの割合-> 30％は、QCがあまり役に立たないことを意味します。
  • _Qcache_hits / Qcache_inserts_-ヒットと挿入の比率-> 10が望ましい
3
Rick James

実際のデータの読み取りと書き込みの分割に大きく依存します。読み込みが重い場合は、query_cacheを使用してスマートにRDSのCPU負荷を節約できます。ただし、デフォルトでONにすることはお勧めしませんが、DEMAND（RDSパラメータの数値2）を使用して、選択ステートメントでSQL_CACHEを使用し、特に煩雑なクエリでディスクにアクセスする可能性を回避できます（非常に低速です）。 RDSは通常）query_cacheがなく、データの期限切れにより、制御不能な方法でDBが引き継がれます。

オプション2を使用すると、最悪のクエリ実行結果をキャッシュするための十分なスペースを確保しながら、query_cache_sizeを小さく保ち、エビクションを回避できます。読み取りが多い状況では、これにより、システムに負荷をかけずに、500GB RDSデータベースを使用した最も遅いクエリの速度が大幅に向上しました。

HTH

1
Ross