gpt4 book ai didi

MySQL 查询缓存 : Yes or No for large website building platform

转载 作者:行者123 更新时间:2023-11-29 01:04:27 24 4
gpt4 key购买 nike

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

提前感谢您的任何建议。

最佳答案

答案是肯定的。

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

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

关于MySQL 查询缓存 : Yes or No for large website building platform,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/10630967/

24 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com