首页
学习
活动
专区
圈层
工具
发布
首页
学习
活动
专区
圈层
工具
MCP广场
社区首页 >问答首页 >MySQL查询缓存:最大缓存大小限制为128MB?

MySQL查询缓存:最大缓存大小限制为128MB?
EN

Stack Overflow用户
提问于 2010-01-20 01:43:03
回答 6查看 93.5K关注 0票数 31

我的应用程序是数据库密集型应用程序,所以我非常努力地确保应用程序和MySQL数据库尽可能高效地协同工作。

目前,我正在调优MySQL查询缓存,使其与服务器上运行的查询的特征保持一致。

query_cache_size是可以存储在缓存中的最大数据量,query_cache_limit是缓存中单个结果集的最大大小。

我当前的MySQL查询缓存配置如下:

代码语言:javascript
运行
复制
query_cache_size=128M
query_cache_limit=1M

tuning-primer.sh给了我以下关于正在运行的系统的调优提示:

代码语言:javascript
运行
复制
QUERY CACHE
Query cache is enabled
Current query_cache_size = 128 M
Current query_cache_used = 127 M
Current query_cache_limit = 1 M
Current Query cache Memory fill ratio = 99.95 %
Current query_cache_min_res_unit = 4 K
However, 21278 queries have been removed from the query cache due to lack of memory
Perhaps you should raise query_cache_size
MySQL won't cache query results that are larger than query_cache_limit in size

mysqltuner.pl给出了以下调优提示:

代码语言:javascript
运行
复制
[OK] Query cache efficiency: 31.3% (39K cached / 125K selects)
[!!] Query cache prunes per day: 2300654

Variables to adjust:
    query_cache_size (> 128M)

两个调优脚本都建议我提高query_cache_size。但是,根据mysqltuner.pl (请参阅http://mysqltuner.pl/),将query_cache size增加到128M以上可能会降低性能。

你将如何解决这个问题?你会无视mysqltuner.pl的警告而增加query_cache_size,还是尝试以某种方式调整查询逻辑?大多数数据访问都是由Hibernate处理的,但在应用程序中也使用了相当多的手工编码的SQL。

EN

回答 6

Stack Overflow用户

回答已采纳

发布于 2010-01-20 01:53:13

通常,“缓存太大”警告是在假设您的物理内存很少,缓存本身需要交换或将占用OS所需的资源(如文件缓存)的情况下发出的。

如果您有足够的内存,增加query_cache size是安全的(我见过使用1GB查询缓存的安装)。

但是您确定您使用的查询缓存是正确的吗?是否有很多逐字重复的查询?你能给出一个典型查询的例子吗?

票数 15
EN

Stack Overflow用户

发布于 2011-11-28 07:24:54

mysqltuner.py发出的警告实际上是相关的,即使您的缓存没有被交换的风险。它在以下方面得到了很好的解释:http://blogs.oracle.com/dlutz/entry/mysql_query_cache_sizing

基本上,缓存越大,MySQL花在整理缓存上的时间就越多,而且即使在中等的写负载下(查询经常被清除),缓存也是非常不稳定的,所以将缓存放得太大会对应用程序性能产生不利影响。调整应用程序的query_cache_sizequery_cache_limit,尝试找到每次插入命中率最高、lowmem_prunes数量较少的临界点,同时密切关注数据库服务器的负载。

票数 20
EN

Stack Overflow用户

发布于 2013-03-28 00:32:38

你应该容易地增加你的缓存,这不仅仅是一个“没有那么多可用内存”的事情!

读一下实例the manual,你会得到这样的引用:

要小心,不要将查询缓存调整得过大,这会增加维护缓存所需的开销,可能会超出启用缓存的好处。以数十兆字节为单位的大小通常是有益的。数百兆字节的大小可能不是。

还有其他的sources你可以去看看!

如果修剪率不为零,则表示您应该增加查询缓存的大小。但是,请记住,维护缓存的开销可能会随着缓存大小的增加而增加,因此请以较小的增量执行此操作,并监视结果。如果您需要大幅增加高速缓存的大小以消除剪枝,则您的工作负载很可能与查询高速缓存不匹配。

因此,不要只在查询缓存中放入尽可能多内容!

最好的办法是逐渐增加查询缓存,并测量站点的性能。这在性能问题中是默认的,但在像这样的情况下,“测试”是你能做的最好的事情之一。

票数 14
EN
页面原文内容由Stack Overflow提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接:

https://stackoverflow.com/questions/2095614

复制
相关文章

相似问题

领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档