3

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

提前感谢您的任何建议。

4

2 回答 2

0

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

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

于 2012-06-06T08:50:16.503 回答
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 回答