MySQL 查询缓存：大型网站建设平台是或否

Posted 2023-02-25

【中文标题】MySQL 查询缓存：大型网站建设平台是或否

【英文标题】：MySQL Query Cache: Yes or No for large website building platform

【发布时间】：2012-05-24 17:59:00

【问题描述】：

阅读关于 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)

提前感谢您的任何建议。

【参考方案1】：

答案是肯定的。

它是无效的，并且它是完全透明的，除非你禁用query_cache_wlock_invalidate，你可能想检查一下，因为如果你使用 MyISAM 表，它仍然值得禁用。

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

【参考方案2】：

上次我查看查询缓存时，这对我来说绝对是禁忌。虽然增加了缓存结果的能力，但它也会使 MySQL 变慢一点，因为它需要时间来使缓存条目无效。除非您针对它测试工作负载，否则我不建议您明确打开它（如手册所示：http://dev.mysql.com/doc/refman/5.1/en/query-cache.html）。

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