您当前的位置:首页>>数据库>>正文
 
MySQL数据库中QueryCache的锁模型
作者: 来源:博客 日期:2013/8/6 17:47:53  点击次数:
1、 QC基本概念
这个是实现在MySQL层(非引擎层)的一个内存结构,基本规则是将满足一定条件的查询结果缓存在内存中,若同样的查询再执行第二次,而且缓存没有失效,则可以直接返回查询结果,无需到引擎获取数据。
几个说明:
a) QC的结构是hash,key为查询字符串的原文,因此若想命中QC,要求查询语句与之前的一模一样,包括大小写必须一致、不能增减空格等等。
b) Qc可以缓存一个表中的多个查询语句和结果。
c) 对一个表的DML或DDL操作都会将与这个表有关的缓存都从QC中删除。
2、 锁模型
于是说到锁的粒度。整个QC在内存中只有一个实例Query_cache query_cache;
我们来看上面c中说到的失效逻辑的部分代码
void Query_cache::invalidate_table(THD *thd, uchar * key, uint32 key_length){ DEBUG_SYNC(thd, “wait_in_query_cache_invalidate1″);
lock();
DEBUG_SYNC(thd, “wait_in_query_cache_invalidate2″);
if (query_cache_size > 0)
invalidate_table_internal(thd, key, key_length);
unlock();
}
可以看到这里lock()没有参数,函数内部用一额全局信号量COND_cache_status_changed,来控制。
因此即使两个dml更新的是不同的表,也会由于都要失效本表在QC中的缓存项而互锁。
因此是“全局锁”。
3、锁策略
得到上述结论后我们有点担心,作为一个全局变量,是否也会锁住“查询”。试想如果我们在作一个DDL时,需要失效这个表的缓存项,而这个锁的时间就会持续很长。 这期间其他表的普通查询,是否也会受影响。 如果是,这个损失太大了。
我们知道,查询过程中的对QC的访问包含两部分 :查询开始之前从QC中判断当前Query的结果是否已经缓存; 若没有,则查询执行完成后,(可能)需要将这个结果插入到QC中。
这两个操作都其实也都需要对QC加锁。这样说来, 这个锁的频度如此之高,以至于我们会担心是否会得不偿失?
更新时失效缓存项是必要的操作,但查询时对QC的操作则不是必须的。MySQL中使用try_lock的策略。简单来说,就是在上面的两个阶段中,试图去加锁,若超时,则放弃。
这个超时时间写死在代码中是50ms,所以若一个 查询期间的两次对QC的操作都出现锁超时,则这个查询会额外耗费100ms的时间。
当然若是dml操作需要失效QC中的项,而碰上锁等待,就必须等了。
4、小结
从上面描述中可以得出一些结论,对于更新操作比较小的服务,开启QC的效果会不错,因为查询期间使用的try_lock策略使得不会出现查询在QC阶段互锁的问题。(这个50ms如果觉得太大,可以在源码中去掉个0)。
当然若是更新频繁的表,还是建议关闭QC。现在主干版本上用参数关闭QC不够彻底,还是会有一些cpu消耗。
上一篇:Oracle完全卸载
下一篇:没有了
  北京总部: 4006-505-646
  天 津 部: 4006-505-646
  上 海 部: 4006-505-646
  深 圳 部: 4006-505-646
  广 州 部: 4006-505-646
  重 庆 部: 4006-505-646
  南 京 部: 4006-505-646
  其它地区: 4006-505-646
经典案例
中国石油管理局-Oracle数据库恢
中国网通-IBM EXP300磁盘阵列数
大连鸿德经贸有限责任公司-SQL
中国地质环境监测院-HP LH3000
藁城市东街百货-EFS文件解密成
工商银行某省分行-AIX删除LV数
中央电视台新闻评论部-苹果分
promise乔鼎硬盘阵列数据恢复成
麒麟童文化-苹果分区无法打开,
NAS 8100服务器数据恢复成功 
解决方案
raid磁盘阵列OFFLINE后的应急方
磁盘未被格式化,是否格式化数据
误GHOST、误一键恢复灾难应急方
误删除、误格式化数据灾难应急
LINUX FSCK数据出错灾难应急方
北亚数据恢复 - 联系我们 - 关于北亚 - 友情链接 - 网站地图 - RSS聚合 
版权所有 北亚数据恢复中心
全国统一客服热线:4006-505-646
北京总部:北京市海淀区永丰基地丰慧中路7号新材料创业大厦B座205室
ine