MySQL Query Cache:对于大型网站构建平台,是或否

时间:2012-05-17 06:35:06

标签: mysql lamp query-cache

在MySQL的查询缓存中浏览如此多的信息和相互矛盾的建议可能真的是压倒性的,很难说它与我的用例有什么关系。

我们在LAMP堆栈上运行一个大型自定义平台,托管许多网站。每个网站的内容都存储在一个表格行中。在大多数情况下,他们都在同一张桌子上。 我已经读过,每当表更新时,所有缓存的查询都会失效,但我也读过有关它的相互矛盾的事情。

说某人访问网站A,其内容从数据库加载并在此过程中缓存。另一个人之后访问,网站加载速度更快,因为数据被缓存。现在网站B的内容已更改,这是与网站A在同一个表中的一行。网站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)

提前感谢任何建议。

2 个答案:

答案 0 :(得分:0)

答案非常肯定。

它是无效的,除非您禁用可能要签出的query_cache_wlock_invalidate,否则它是完全透明的,因为如果您使用MyISAM表,它仍然值得禁用。

然而,它节省了16%的读取查询并立即解决它们而不会打扰存储引擎,在MyISAM的情况下,这通常意味着不会打扰I / O系统。这太棒了!事实上,查询缓存是关于缓存RAM的最佳方法,因此将查询缓存设置为128 MB,并且在一些正常/重度操作之后,SHOW GLOBAL STATUS LIKE '%qcache%'显示低或高Qcache_free_memory:如果它很低,请增加查询缓存,即使以其他数据库缓存(例如InnoDB缓冲池)为代价;如果它很高,请将查询缓存减少几乎那么多,因为很遗憾,您不会在工作集中使用更多的查询缓存。

答案 1 :(得分:0)

上次我查看查询缓存时,对我来说这绝对不是。在添加缓存结果的能力的同时,它也会减慢MySQL的速度,因为无效缓存条目需要时间。除非您根据它测试工作量,否则我不建议明确启用它(如手册所示:http://dev.mysql.com/doc/refman/5.1/en/query-cache.html)。

测试它的好方法是快照数据库并捕获以下1小时的请求。通过这种方式,您可以设置另一台服务器并在那里运行所有测试,而无需大量加载生产机器。