注册 登录  
 加关注
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

网事

备忘录

 
 
 

日志

 
 

mysql sql no cache  

2012-02-01 14:00:45|  分类: mysql |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |

缓存2(SQL_NO_CACHE和SQL_CACHE 的区别)  

可以在 SELECT 语句中指定查询缓存的选项,对于那些肯定要实时的从表中获取数据的查询,或者对于那些一天只执行一次的查询,我们都可以指定不进行查询缓存,使用 SQL_NO_CACHE 选项。

对于那些变化不频繁的表,查询操作很固定,我们可以将该查询操作缓存起来,这样每次执行的时候不实际访问表和执行查询,只是从缓存获得结果,可以有效地改善查询的性能,使用 SQL_CACHE 选项。

下面是使用 SQL_NO_CACHE 和 SQL_CACHE 的例子:

mysql> select sql_no_cache id,name from test3 where id < 2;

mysql> select sql_cache id,name from test3 where id < 2;

注意:查询缓存的使用还需要配合相应得服务器参数的设置。

 

本文是整理 chapter 5. Advance MySQL features 部分观点所得。 

  1. 何时cache

  a) mysql query cache内容为 select 的结果集, cache 使用完整的 sql 字符串做 key, 并区分大小写,空格等。即两个sql必须完全一致才会导致cache命中。 

  b) prepared statement永远不会cache到结果,即使参数完全一样。据说在 5.1 之后会得到改善。 

  c) where条件中如包含了某些函数永远不会被cache, 比如current_date, now等。 

  d) date 之类的函数如果返回是以小时或天级别的,最好先算出来再传进去。 

  select * from foo where date1=current_date -- 不会被 cache

  select * from foo where date1='2008-12-30' -- 被cache, 正确的做法 

  e) 太大的result set不会被cache (< query_cache_limit) 

  2. 何时invalidate 

  a) 一旦表数据进行任何一行的修改,基于该表相关cache立即全部失效。 

  b) 为什么不做聪明一点判断修改的是否cache的内容?因为分析cache内容太复杂,服务器需要追求最大的性能。

  3. 性能 

  a) cache 未必所有场合总是会改善性能 

  当有大量的查询和大量的修改时,cache机制可能会造成性能下降。因为每次修改会导致系统去做cache失效操作,造成不小开销。 

  另外系统cache的访问由一个单一的全局锁来控制,这时候大量>的查询将被阻塞,直至锁释放。所以不要简单认为设置cache必定会带来性能提升。 

  b) 大result set不会被cache的开销 

  太大的result set不会被cache, 但mysql预先不知道result set的长度,所以只能等到reset set在cache添加到临界值 query_cache_limit 之后才会简单的把这个cache 丢弃。这并不是一个高效的操作。如果mysql status中Qcache_not_cached太大的话, 则可对潜在的大结果集的sql显式添加 SQL_NO_CACHE 的控制。 

  query_cache_min_res_unit = (query_cache_size – Qcache_free_memory) / Qcache_queries_in_cache 

  4. 内存池使用 

  mysql query cache 使用内存池技术,自己管理内存释放和分配,而不是通过操作系统。内存池使用的基本单位是变长的block, 一个result set的cache通过链表把这些block串起来。因为存放result set的时候并不知道这个resultset最终有多大。block最短长度为 query_cache_min_res_unit, resultset 的最后一个block会执行trim操作。 

  (引用:High Performance MySQL 原书Figure 5-1 插图) 

  定长:空间浪费 

  变长:需清理碎片 

  block 小: 链表超长,访问大块数据效率低。 

  评论这张
 
阅读(2451)| 评论(0)
推荐 转载

历史上的今天

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2018