MySQL案例分析--QueryCache

QueryCache联动内容:http://blog.itpub.net/29510932/viewspace-1694922/
-------------------------------------------------------------------------------------------------正文---------------------------------------------------------------------------------------------------------------
案例发生于生产环境,由于是临时的技术支持,截图没有了.....

场景:
M
ySQL-5.5.47, 隔离级别RR
背景:
业务人员反应数据库操作时不时出现非常明显的卡顿, 与此同时慢日志中出现大量的SQL;
问题的现象&排查:
1.先看监控图表: 发现CPU使用率,IO吞吐量, IO Utils, 网卡in/out流量, 内存的使用率都没有异常现象----应该不是服务器资源造成的;
2.登录到生产库,看一下processlist的情况,并没有明显的长连接或者长事务,咨询了开发人员,在应用层也没有手动开启长事务----应该和特殊的SQL或者事务没什么关系;
3.开发人员反馈并没有触发器/存储过程/定时任务----又排除几个影响因素;
4.查看了一下当天的慢日志,在某一个随机的时间点, 会出现很多的慢查询, 而且慢查询都是成片成片出现的, 成片出现的慢查询都有相同的TIMESTAMP----随机事件,可能是非人为的;
5.这种成片出现的慢查询, 全部是以Insert, Update这种DML作为前N条;

问题分析:
在排查过程中,初步得出的结论:
可能是SQL的问题; 而且设置的隔离级别是RR, 结合排查的第五点,感觉可能会是锁等待导致的;
在生产环境查看了一下这些DML表的结构,发现相关的索引都有, 也在测试环境试了一下, 发现这些DML并没有出现锁等待的现象;

用mysqldumpslow给某个时间点的近300条慢查询语句做了个统计, 发现DML语句大约只有10%多一点的样子,绝大多数还是select;
之后粗略看了一下这些select语句, explain的结果基本都是const, 说明这些语句本身并没有问题;

在这个过程中,发现一个现象:
这些select语句,约70%都是DML的那几张表, 而且不论什么类型select语句,记录下来的时间都是基本一致的,2.78-2.80秒之间;
疑点1:虽然不是很确定这种现象是不是有什么意义, 不过看上去像是由于这几张表进行了DML, 结果堵住了很多对这几张表的查询;
疑点2:除非是IO出现了波动或者峰值/没有索引/锁等待, 否则DML语句应该很少会出现在慢查询日志里面;

猜测是cache或者是buffer的设置问题, 于是去my.cnf检查一下配置, 然后看到了query_cache_size的设置;query_cache_size=256M
参考联动内容,其实Query Cache远没有发挥想象中作用,不过>=5.6.8和5.7的版本中,query_cache_type默认都是关闭的, 5.5并不太清楚, 难道是这个Query_cache的问题?
翻了一下5.5的文档,发现query_cache_type的默认值是开启的, 但是size的默认值是0, 意味着如果什么都不动,那就是屏蔽了Query Cache,
然而配置文件里面修改了size, 所以Query Cache就开启了;

Query Cache的缺陷,在另一篇博文里面有描述, 对应到这次案例中的疑点1和疑点2, 做出几个推断:
在某个时间点内,应用层发起较多的DML,这些DML会尝试获取cache中某几张表的mutex,所以在慢查询中,在每个时间点,都是最先出现了Insert和Update(互相等待mutex);
由于Query Cache中,由于相关表的数据被清理,select会重新生成对应的result写入到Query Cache, 并且还存在并发的DML语句,导致频繁的在清空和写入Query Cache;
由于Query Cache设置得比较大,如果保存了大量的数据,那么在获取mutex, 并清理数据的时候, 也会消耗更多的时间;

联系运维人员,查看了一下生产库的Qcache的status,如下图

可以看到在mysql启动之后,Qcache触发了约1.2亿次的insert,但是只有约870万次的缓存命中;
这一组统计数据也基本验证了Query Cache不好用这一事实;

处理方式:
考虑到Qcache的统计结果,在线上库关掉应该也不会有什么问题,所以和相关运维人员说明了情况,在最近的维护时间内关掉这个Query Cache,然后观察一段时间;
反馈结果:
卡顿现象暂时消失了,慢日志也不再出现;
PS:Query Cache的问题多多,除非几乎没有DML,否则还是尽量不要开启的比较好

时间: 2024-09-15 20:15:46

MySQL案例分析--QueryCache的相关文章

MySQL运维案例分析:Binlog中的时间戳

背景 众所周知,在Binlog文件中,经常会看到关于事件的时间属性,出现的方式都是如下这样的. #161213 10:11:35 server id 11766 end_log_pos 263690453 CRC32 0xbee3aaf5 Xid = 83631678 我们清楚地知道,161213 10:11:35表示的就是时间值,但除此之外呢?还能知道它的什么信息呢? 案例分析 先从一个典型的案例入手来讲述其中的细节,比如曾经在Galera Cluster碰到的一个问题,可以先看一段Binlo

MySQL下的RAND()优化案例分析_Mysql

众所周知,在MySQL中,如果直接 ORDER BY RAND() 的话,效率非常差,因为会多次执行.事实上,如果等值查询也是用 RAND() 的话也如此,我们先来看看下面这几个SQL的不同执行计划和执行耗时. 首先,看下建表DDL,这是一个没有显式自增主键的InnoDB表: [yejr@imysql]> show create table t_innodb_random\G *************************** 1. row *************************

MySQL索引优化的实际案例分析_Mysql

Order by desc/asc limit M是我在mysql sql优化中经常遇到的一种场景,其优化原理也非常的简单,就是利用索引的有序性,优化器沿着索引的顺序扫描,在扫描到符合条件的M行数据后,停止扫描:看起来非常的简单,但是我经常看到很多性能较差的sql没有利用这个优化规律,下面将结合一些实际的案例来分析说明: 案例一: 一条sql执行非常的慢,执行时间为: root@test 02:00:44 SELECT * FROM test_order_desc WHERE END_TIME>

【阿里在线技术峰会】罗龙九:云数据库十大经典案例分析

本文根据阿里云资深DBA专家罗龙九在首届阿里巴巴在线峰会的<云数据库十大经典案例分析>的分享整理而成.罗龙九以MySQL数据库为例,分析了自RDS成立至今,用户在使用RDS过程中最常见的问题,包括:索引.SQL优化.锁.延迟.参数优化.连接数.CPU.Iops.磁盘.内存等.罗龙九通过对十大经典案例的总结,还原问题原貌,给出分析问题的思路,旨在帮助用户在使用RDS的路上少一些弯路,多一些从容. 直播视频 (点击图片查看视频) 幻灯片下载:点此进入 以下为整理内容. 案例一:索引 今天之所以将索

PHP文件上传处理案例分析_php技巧

本文实例讲述了PHP文件上传处理的方法.分享给大家供大家参考,具体如下: 最近遇到一个事,把自己坑了好久,我想说说我开始的想法 PHP的上传机制封装的很完全,基本几行代码就能实现,他的实现流程是这样的 UPLOAD到文件到临时目录中–>使用move_uploadde_file()到指定的目录 这就是PHP上传流程,或者你在中途再进行一些验证.例如判断是不是通过upload方式提交的文档,或者文件的扩展是不是我们允许的 等等一系列验证.我给出简单的代码也算是抛砖引玉了. $targetFolder

PHP数组操作简单案例分析_php技巧

本文实例讲述了PHP数组操作相关技巧.分享给大家供大家参考,具体如下: 这个是一道简单的PHP数组入门题 $Str = "as5454654%^$%^$7675dhasjkdhh12u123123asdasd"; //将上面的统计上面字符串不同字符和出现的次数. 实现方式:将字符串转换成数组,在通过对数组的操作得到相应的结果. $len = strlen($str); //数组存在数组中 $array = array(); for($i=0;$i<$len;$i++) { arr

案例分析:如何将免费社区转化为成功的商业模式

社区 Nisan Gabbay注:非常高兴本周的案例分析出自Startup Review的读者Kempton Lam. Kempton是一位管理咨询师,专于创业指导,您可以查看Kempton的背景及博客.Kempton采用了和我相同的案例分析流程,作为编辑,我的工作是确保其与Startup Review保持格式上的一致.如果你有意成为Startup Review的嘉宾作者,请与我联系. 为什么研究这个案例 iStockphoto既是一个摄影师社区,也是一个高质低价的庞大图片库.到2006年10月

Digg&amp;nbsp;案例分析:为什么技术人群是重要的用户

一直觉得Digg是我错过的了一个Web2.0应用,想去研究研究一下,感谢丁丁提供的译文! Digg 案例分析:为什么技术人群是重要的用户原文作者:Nisan Gabbay***:雷声大雨点大原文链接:Digg Case Study: Why techies are an important audience原文发表时间:2006年10月15日 为什么做这个案例分析从2004年12月面世至今,Digg已经成为Web2.0的成功典型.Digg是一个提供新闻内容的网站,它一反传统的层层审核的编辑制度.

广场舞案例分析深入思考二:别样冲突

前面对于Robin广场舞案例从我个人的角度作了深入思考,可能都是一些基础的技巧,但是运用到全面的SEO工作当中还是相当不错的一些技巧,尤其是对没有形成体系的朋友显得尤为重要.最近在不少群里面见到有些朋友认为SEO很简单,个人还是有点担忧,因为SEO真的不是那么简单,而且要真正的学好SEO,这里指的不仅仅是执行的SEO,而是要真正要建立良好的SEO知识结构体系和SEO全局观的SEO. 当然,这两个问题并不是今天我要跟大家谈的想法,后面如果有机会可以跟大家多探讨探讨.今天我要跟大家交流的依然是关于广