3
涉及MySQL的查询缓存中如此多的信息和冲突的建议可能真的令人难以置信，很难说明它与我的用例有何关系。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)
在此先感谢您的任何建议。