MySQL查询缓存:大型建站平台支持或不支持

Question

在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)

提前感谢您的建议。

Answer 1

答案将是非常肯定的。

它是无效的，并且它是完全透明的，除非您禁用了query_cache_wlock_invalidate，因为如果您使用MyISAM表，那么仍然值得禁用它。

然而，它节省了16%的读查询并立即解决它们，而不会干扰存储引擎，在MyISAM的情况下，这通常意味着不会干扰I/O系统。这已经足够好了！事实上，查询缓存是使用内存进行缓存的最佳选择，因此将查询缓存设置为128MB左右，在一些正常/繁重的操作之后，SHOW GLOBAL STATUS LIKE '%qcache%'会显示出较低或较高的Qcache_free_memory：如果较低，则增加查询缓存，即使以牺牲其他数据库缓存(如InnoDB缓冲池)为代价；如果较高，则将查询缓存减少差不多那么多，因为不幸的是，您将无法在工作集中使用更多的查询缓存。

Answer 2

上一次我查看查询缓存时，它对我来说绝对是个禁忌。虽然增加了缓存结果的能力，但它也会使MySQL变慢，因为它需要时间来使缓存条目无效。我不建议显式地启用它，除非您针对它来测试您的工作负载(正如手册所建议的：http://dev.mysql.com/doc/refman/5.1/en/query-cache.html)。

测试它的好方法是对数据库进行快照，并捕获以下1小时的请求。这样，您可以设置另一台服务器并在那里运行所有测试，而不会给生产机器带来沉重的负载。