MySQL Query Cache 小结

Hibernate的QueryPlanCache引发的堆内存溢出 事情缘由 协助康美中药网排查内存溢出的问题。这个系统是基于Hibernate3开发的一个药品信息、价格变动、药品咨询新闻相关的网站,90%的操作都是查询。 问题日志 工具排查 使用Java VisualVM进行观察,发现一段时间后堆内存持续上升。 Dump堆内存文件,使用MAT进行分析 1、jsp 命令获取应用的pid jmap -dump:format=b,file=/dump.hprof pid 分析后发现: MAT中已经给出有可能出问题的代码位置。Session 阅读详情
作者:Sky.Jian | 可以任意转载, 但转载时务必以超链接形式标明文章原始出处 和 作者信息 及 版权声明 
链接:http://isky000.com/database/mysql-query-cache-summary |  del.icio.us | Twitter it | 
 
Hosted On DreamHost 可以通过我的折扣码 iMySQLer 获得优惠折扣

最近经常有人问我 MySQL Query Cache 相关的问题,就整理一点 MySQL Query Cache 的内容,以供参考。

顾名思义,MySQL Query Cache 就是用来缓存和 Query 相关的数据的。具体来说,Query Cache 缓存了我们客户端提交给 MySQL 的 SELECT 语句以及该语句的结果集。大概来讲,就是将 SELECT 语句和语句的结果做了一个 HASH 映射关系然后保存在一定的内存区域中。

在大部分的 MySQL 分发版本中,Query Cache 功能默认都是打开的,我们可以通过调整 MySQL Server 的参数选项打开该功能。主要由以下5个参数构成:

  • query_cache_limit:允许 Cache 的单条 Query 结果集的最大容量,默认是1MB,超过此参数设置的 Query 结果集将不会被 Cache
  • query_cache_min_res_unit:设置 Query Cache 中每次分配内存的最小空间大小,也就是每个 Query 的 Cache 最小占用的内存空间大小
  • query_cache_size:设置 Query Cache 所使用的内存大小,默认值为0,大小必须是1024的整数倍,如果不是整数倍,MySQL 会自动调整降低最小量以达到1024的倍数
  • query_cache_type:控制 Query Cache 功能的开关,可以设置为0(OFF),1(ON)和2(DEMAND)三种,意义分别如下:
    • 0(OFF):关闭 Query Cache 功能,任何情况下都不会使用 Query Cache
    • 1(ON):开启 Query Cache 功能,但是当 SELECT 语句中使用的 SQL_NO_CACHE 提示后,将不使用Query Cache
    • 2(DEMAND):开启 Query Cache 功能,但是只有当 SELECT 语句中使用了 SQL_CACHE 提示后,才使用 Query Cache
  • query_cache_wlock_invalidate:控制当有写锁定发生在表上的时刻是否先失效该表相关的 Query Cache,如果设置为 1(TRUE),则在写锁定的同时将失效该表相关的所有 Query Cache,如果设置为0(FALSE)则在锁定时刻仍然允许读取该表相关的 Query Cache。

Query Cache 如何处理子查询的?
这是我遇到的最为常见的一个问题。其实 Query Cache 是以客户端请求提交的 Query 为对象来处理的,只要客户端请求的是一个 Query,无论这个 Query 是一个简单的单表查询还是多表 Join,亦或者是带有子查询的复杂 SQL,都被当作成一个 Query,不会被分拆成多个 Query 来进行 Cache。所以,存在子查询的复杂 Query 也只会产生一个Cache对象,子查询不会产生单独的Cache内容。UNION[ALL] 类型的语句也同样如此。

Query Cache 是以 block 的方式存储的数据块吗?
不是,Query Cache 中缓存的内容仅仅只包含该 Query 所需要的结果数据,是结果集。当然,并不仅仅只是结果数据,还包含与该结果相关的其他信息,比如产生该 Cache 的客户端连接的字符集,数据的字符集,客户端连接的 Default Database等。

Query Cache 为什么效率会非常高,即使所有数据都可以 Cache 进内存的情况下,有些时候也不如使用 Query Cache 的效率高?
Query Cache 的查找,是在 MySQL 接受到客户端请求后在对 Query 进行权限验证之后,SQL 解析之前。也就是说,当 MySQL 接受到客户端的SQL后,仅仅只需要对其进行相应的权限验证后就会通过 Query Cache 来查找结果,甚至都不需要经过 Optimizer 模块进行执行计划的分析优化,更不许要发生任何存储引擎的交互,减少了大量的磁盘 IO 和 CPU 运算,所以效率非常高。

客户端提交的 SQL 语句大小写对 Query Cache 有影响吗?
有,由于 Query Cache 在内存中是以 HASH 结构来进行映射,HASH 算法基础就是组成 SQL 语句的字符,所以必须要整个 SQL 语句在字符级别完全一致,才能在 Query Cache 中命中,即使多一个空格也不行。

一个 SQL 语句在 Query Cache 中的内容,在什么情况下会失效?
为了保证 Query Cache 中的内容与是实际数据绝对一致,当表中的数据有任何变化,包括新增,修改,删除等,都会使所有引用到该表的 SQL 的 Query Cache 失效。

为什么我的系统在开启了 Query Cache 之后整体性能反而下降了?
当开启了 Query Cache 之后,尤其是当我们的 query_cache_type 参数设置为 1 以后,MySQL 会对每个 SELECT 语句都进行 Query Cache 查找,查找操作虽然比较简单,但仍然也是要消耗一些 CPU 运算资源的。而由于 Query Cache 的失效机制的特性,可能由于表上的数据变化比较频繁,大量的 Query Cache 频繁的被失效,所以 Query Cache 的命中率就可能比较低下。所以有些场景下,Query Cache 不仅不能提高效率,反而可能造成负面影响。

如何确认一个系统的 Query Cache 的运行是否健康,命中率如何,设置量是否足够?
MySQL 提供了一系列的 Global Status 来记录 Query Cache 的当前状态,具体如下:

  • Qcache_free_blocks:目前还处于空闲状态的 Query Cache 中内存 Block 数目
  • Qcache_free_memory:目前还处于空闲状态的 Query Cache 内存总量
  • Qcache_hits:Query Cache 命中次数
  • Qcache_inserts:向 Query Cache 中插入新的 Query Cache 的次数,也就是没有命中的次数
  • Qcache_lowmem_prunes:当 Query Cache 内存容量不够,需要从中删除老的 Query Cache 以给新的 Cache 对象使用的次数
  • Qcache_not_cached:没有被 Cache 的 SQL 数,包括无法被 Cache 的 SQL 以及由于 query_cache_type 设置的不会被 Cache 的 SQL
  • Qcache_queries_in_cache:目前在 Query Cache 中的 SQL 数量
  • Qcache_total_blocks:Query Cache 中总的 Block 数量

可以根据这几个状态计算出 Cache 命中率,计算出 Query Cache 大小设置是否足够,总的来说,我个人不建议将 Query Cache 的大小设置超过256MB,这也是业界比较常用的做法。

MySQL Cluster 是否可以使用 Query Cache?

其实在我们的生产环境中也没有使用 MySQL Cluster,所以我也没有在 MySQL Cluster 环境中使用 Query Cache 的实际经验,只是 MySQL 文档中说明确实可以在 MySQL Cluster 中使用 Query Cache。从 MySQL Cluster 的原理来分析,也觉得应该可以使用,毕竟 SQL 节点和数据节点比较独立,各司其职,只是 Cache 的失效机制会要稍微复杂一点。

Hibernate参数设置一览表 232 博文链接:https://yfddht1573.iteye.com/blog/219042 立即下载

相关推荐

飞腾X100芯片GPU状态查询

本文档对在linux系统下查看X100芯片GPU状态信息进行说明,可以帮助大家了解芯片的实时工作状态。

乌拉大喵喵 2814

(转)MySQL Query Cache 说明及应用中问题解答

  文章作者:Sky.Jian   原文链接:MySQL Query Cache小结         顾名思义,MySQL Query Cache 就是用来缓存和 Query 相关的数据的。具体来说,Query Cache 缓存了我们客户端提交给 MySQL 的 SELECT 语句以及该语句的结果集。大概来讲,就是将 SELECT 语句和语句的结果做了一个 HASH 映射关系然后保存在一定的...

田维宝博客 293

ADS1293心电图模块实战:从电极贴片到信号采集的全流程指南

本文提供了一份基于TI ADS1293芯片的心电图采集系统全流程实战指南。文章深入探讨了从电极贴片选择与皮肤预处理、ADS1293前端配置(包括PGA、RLD和威尔逊网络),到PCB布局、电源去耦以及固件滤波与运动伪影处理等关键环节,旨在帮助硬件工程师和嵌入式开发者构建稳定可靠的可穿戴心电监测设备。

weixin_29201313的博客 384

MySQL · 特性分析 · 执行计划缓存设计与实现

如果当前用户频繁使用相似的query进行查询,Plan Cache可以有效的减少query的优化时间,进而提升query的执行性能。目前Plan Cache是我们开发的第一个版本,只是针对我们线上的场景进行优化,很多场景还不支持。希望在未来的时间里可以完善Plan Cache,提供更多的场景支持。

Lixora's DB Home 693

Unity通用Buff系统,Buff编辑器(1,理论篇)(技能系统之Buff篇)

逻辑层根据游戏的规则和设计,控制Buff的生命周期、影响目标对象的属性或行为,以及处理Buff的交互和冲突。Buff堆叠和冲突:有些游戏中允许同类型的Buff叠加,以增加效果的强度,而有些游戏中可能不允许Buff叠加,只能由更强力的Buff来覆盖较弱的Buff。灵活个性化:每个游戏对象拥有自己的BuffManager,可以实现个体对象的独特Buff效果,增加游戏的多样性和个性化。自由控制:每个对象独立管理自己的Buff,可以自由地激活、更新和移除Buff效果,提供更精细的控制和逻辑实现。

u010082265的博客 4693

化学气相沉积CVD工艺中MKS下游排气高速节流阀的国产化替代方案及产品

对标MKS、VAT和CDK等国外公司的下游排气高速节流阀系列产品,本文介绍了相应的国产化替代方案和产品。基于CVD工艺,技术方案将下游流量调节阀变为了下游压力调节阀,并采用分体结构,将调压阀与PID控制器分离,调压阀具备大口径和高速功能,电子气控驱动调压阀快速动作,PID控制器接收真空计信号和控制气控驱动阀,可实现阀门全开时间小于0.1秒。

Shanghai_Eyoung的博客 5259

MySQL缓存Query Cache (转)

原理QueryCache(下面简称QC)是根据SQL语句来cache的。一个SQL查询如果以select开头,那么MySQL服务器将尝试对其使用QC。每个Cache都是以SQL文本作为key来存的。在应用QC之前,SQL文本不会被作任何处理。也就是说,两个SQL语句,只要相差哪怕是一个字符(例如大小写不一样;多一个空格等),那么这两个SQL将使用不同的一个CACHE。 不过SQL文本有可能

互联网思想 2570

谷歌浏览器崩溃排查:闪退、卡死、网页打不开的修复指南

浏览器多进程架构通过进程隔离、GPU加速和扩展沙箱提升网页渲染效率,但配置损坏、扩展冲突、显卡驱动异常或系统资源不足时,常会以闪退、卡死、白屏、内存占用飙升和能上微信却打不开网页等形式暴露。排查价值在于先分层定位系统、进程、配置扩展与网页内容,再用无痕模式、chrome://crashes、chrome://gpu和浏览器任务管理器收集证据,避免盲目重装。对办公、开发运维和日常维护场景,禁用扩展、关闭硬件加速、刷新DNS缓存、重置配置文件乃至干净重装,都是可复用的工程化处置手段。围绕谷歌浏览器崩溃的典型症状

weixin_34138056的博客 425

记一个内存泄漏问题:Query Plan Cache BoundedConcurrentHashMap占用堆内存

原因是hibernate会缓存sql语句以减少重复编译,便于直接命中提高效率。这个缓存默认最大值为2G,且在使用in时,只要in后面的参数有任何一个不一样的,就会视为不同的语句而保存下来。 解决这个问题可以将缓存最大值改小。 我看大家都是这样写的: spring: jpa: properties: hibernate: query: plan_cache_max_size: 64 plan_parameter_metadata_

yogima的博客 4505

第8章-认知工程:构建Agent的认知飞轮与自进化《万物皆映射》

认知架构(Cognitive Architecture)是一个系统组织和运行其认知过程的整体设计。对人类而言,认知架构是大脑的结构和功能组织方式;对 AI Agent 而言,认知架构是它处理信息、做出决策、学习经验的系统设计。固定映射 vs 进化映射维度固定映射 Agent进化映射 Agent知识静态(训练时确定)动态(持续积累)策略固定(设计时确定)自适应(经验驱动)工具预定义自主发现/创建错误处理硬编码规则从错误中学习能力边界固定持续扩展在认知工程中,技能。

AI天才研究院 105

Codex 的 AGENTS.md 到底怎么写?前端、后端两套实战模板,照抄就能用

文件名是大写AGENTS.md,放在项目根目录构建、测试、类型检查命令都是可直接复制执行的只写了 Agent 从代码里推断不出来的约定红线规则用了明确的否定句式(禁止/不要/Never)标注了自动生成目录和禁止修改的模块写清了交付要求(改动清单 + 验证命令 + 风险说明)没有任何密钥、密码、连接串整体一页能看完,核心要点 10 条以内每一条都能通过"删掉会不会更容易犯错"的测试一份短小精准的 AGENTS.md,比一份充斥模糊规则的长文件有用得多。

篮球界最会写bug的人;程序猿中打球最菜的人。 610

[转]MySQL Query Cache 小结

转载自:http://isky000.com/database/mysql-query-cache-summary 作者:Sky.Jian| 可以任意转载, 但转载时务必以超链接形式标明文章原始出处 和 作者信息 及版权声明链接:http://isky000.com/database/mysql-query-cache-summary|del.icio.us|Twit...

aqc802886的博客 123

【Bug已解决】openclaw max turns reached / Tool calls exceeded limit — OpenClaw 最大轮次超限解决方案

OpenClaw 在执行过程中达到最大轮次限制任务未完成,本质是 --max-turns 设置过小或任务过于复杂。文中给出增加轮次、--continue 继续、分步执行等完整方案。

一键难忘的博客 5505

LSTM电力负荷预测在MyEMS能源管理平台中的落地实践

时间序列预测是能源管理系统的核心技术之一,通过对历史负荷数据的建模,能够为电力调度提供决策依据。长短期记忆网络(LSTM)作为循环神经网络的改进结构,通过门控机制有效解决了长期依赖问题,在具有强周期性和连续性的电力负荷数据上表现尤为出色。高精度的负荷预测可以直接应用于基本电费优化、电力市场化交易偏差控制以及储能系统协调控制等场景,显著提升能源运行的经济性与可靠性。围绕开源能源管理系统MyEMS的实战经验,完整复盘了从数据清洗、特征工程到LSTM模型训练、评估与上线部署的全流程,并针对数据质量、长假开工等异常

weixin_34406086的博客 399

SAP B1中文培訓教材_SDK

公司内部培训资料,对开发工具 ,DIAPI, UIAPI,Add-ON有详细解说

RU DOS版、EFI版32bit/64bit BIOS常用工具

DOS版、EFI版的RU工具,可用来查看IO、MEM、PCI、SMBIOS等资源。亲测在EFI SHELL下可用。

上一篇: 针对mysql innodb配置的优化
下一篇: HTTP错误总节400 403 401 404
Kyle__Shaw
博客等级 码龄18年 43粉丝 44原创
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付:10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值