https://jackxiang.com/index.php zh-cn https://jackxiang.com/post// jack <xdy108@126.com> Wed, 16 Jun 2010 02:08:43 +0000 https://jackxiang.com/post//
query_cache_type 0 代表不使用缓冲; 1 代表使用缓冲; 2 代表根据需要使用.

开启QC后,对于频繁更新的表, 使用 SQL_NO_CACHE 屏蔽cache, 如: SELECT SQL_NO_CACHE * FROM test.test001 WHERE …. ;

如果QC类型为2, 在需要cache时, 使用 SQL_CACHE 打开缓存, 如: SELECT SQL_CACHE * FROM test.test001 WHERE … ;

网上摘录了一段说明:

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操作。

还有一个比较全的: http://www.surfchen.org/wiki/MySQL优化#Query_Cache
MySQL Query Cache 效率的计算
]]> https://jackxiang.com/post//#blogcomment <user@domain.com> Thu, 01 Jan 1970 00:00:00 +0000 https://jackxiang.com/post//#blogcomment