3

MySQL のクエリ キャッシュに関する非常に多くの情報と相反するアドバイスを検討することは、本当に圧倒され、それが私のユース ケースにどのように関係するかを伝えるのが難しい場合があります。

多くの Web サイトをホストする LAMP スタックで実行される大規模なカスタム プラットフォームがあります。各 Web サイトのコンテンツは、テーブルの行に格納されています。ほとんどの場合、それらはすべて同じテーブルにあります。テーブルが更新されるたびに、キャッシュされたすべてのクエリが無効になることを読みましたが、それについて矛盾することも読みました。

誰かが Web サイト A にアクセスし、そのコンテンツがデータベースから読み込まれ、その過程でキャッシュされたとします。その直後に別の人がアクセスすると、データがキャッシュされているため、サイトの読み込みが速くなります。Web サイト B のコンテンツが変更されました。これは、Web サイト A と同じテーブルの行です。Web サイト A からキャッシュされたすべてのデータは無効になっていますか? もしそうなら、クエリキャッシュを完全にオフにすることで実際にパフォーマンスが向上するでしょうか?

私はクエリキャッシュのチューニングについて読んでいますが、やはり非常に圧倒されます。いくつか試してみましたが、どれだけの効果があったかわかりません。以下は、MySQLTunerscript からの現在の貼り付けです。

-------- General Statistics --------------------------------------------------
[--] Skipped version check for MySQLTuner script
[OK] Currently running supported MySQL version 5.1.62-cll
[OK] Operating on 64-bit architecture

-------- Storage Engine Statistics -------------------------------------------
[--] Status: +Archive -BDB -Federated +InnoDB -ISAM -NDBCluster
[--] Data in MyISAM tables: 4G (Tables: 1977)
[--] Data in InnoDB tables: 384K (Tables: 16)
[!!] Total fragmented tables: 33

-------- Security Recommendations  -------------------------------------------
[OK] All database users have passwords assigned

-------- Performance Metrics -------------------------------------------------
[--] Up for: 5d 1h 30m 33s (53M q [122.486 qps], 1M conn, TX: 125B, RX: 13B)
[--] Reads / Writes: 83% / 17%
[--] Total buffers: 8.1G global + 5.5M per thread (500 max threads)
[OK] Maximum possible memory usage: 10.8G (46% of installed RAM)
[OK] Slow queries: 0% (2K/53M)
[OK] Highest usage of available connections: 5% (28/500)
[OK] Key buffer size / total MyISAM indexes: 8.0G/1.2G
[OK] Key buffer hit rate: 99.7% (1B cached / 3M reads)
[!!] Query cache efficiency: 16.2% (6M cached / 41M selects)
[!!] Query cache prunes per day: 2869188
[OK] Sorts requiring temporary tables: 0% (11 temp sorts / 609K sorts)
[OK] Temporary tables created on disk: 0% (11K on disk / 2M total)
[OK] Thread cache hit rate: 99% (28 created / 1M connections)
[!!] Table cache hit rate: 1% (1K open / 88K opened)
[OK] Open file limit used: 3% (2K/65K)
[OK] Table locks acquired immediately: 99% (41M immediate / 41M locks)
[OK] InnoDB data size / buffer pool: 384.0K/8.0M

-------- Recommendations -----------------------------------------------------
General recommendations:
    Run OPTIMIZE TABLE to defragment tables for better performance
    Enable the slow query log to troubleshoot bad queries
    Increase table_cache gradually to avoid file descriptor limits
Variables to adjust:
    query_cache_limit (> 6M, or use smaller result sets)
    query_cache_size (> 96M)
    table_cache (> 1024)

アドバイスをよろしくお願いします。

4

2 に答える 2

0

答えは非常にイエスです。

query_cache_wlock_invalidateこれは無効になっており、MyISAMテーブルを使用する場合は無効にする価値がある可能性があるため、チェックアウトする可能性のあるものを無効にしない限り、完全に透過的です。

それでも、読み取りクエリの16％を節約し、ストレージエンジンを気にせずにすぐに解決できます。これは、MyISAMの場合、ほとんどの場合、I/Oシステムも気にしないことを意味します。これで十分です！実際のところ、クエリキャッシュは、キャッシュ用のRAMを使用するのに最適です。したがって、クエリキャッシュを128 MBのように設定すると、通常の/重い操作の後にSHOW GLOBAL STATUS LIKE '%qcache%'、低または高が表示されます。低Qcache_free_memoryの場合は、 InnoDBバッファープールなどの他のデータベースキャッシュを犠牲にしても、クエリキャッシュを増やします。高い場合は、クエリキャッシュをほぼ同じくらい減らします。残念ながら、ワークセットでそれ以上使用することはできません。

于 2012-06-06T08:37:23.520 に答える