详解 MySQL 中的查询缓存 Query Cache 用法与性能

发布于 2019-07-23 19:19:17 字数 3484 浏览 2284 评论 0

我们总是抱怨 MySQ L的查询速度慢,其实 MySQL 也有缓存机制,意思是将 Select 查询的结果集和 SQL 语句映射到内存缓存起来。当有存在缓存数据的时候,服务器马上返回服务器的结果,跳过解析 SQL 的过程。

MySQL Query Cache 默认为打开。从某种程度可以提高查询的效果,但是未必是最优的解决方案,如果有的大量的修改和查询时,由于修改造成的 Cache 失效,会给服务器造成很大的开销,可以通过 query_cache_type 设置参数来控制缓存的开关,可选参数:0(OFF)1(ON)2(DEMAND)。

需要注意的是 MySQL Query Cache 是对大小写敏感的,因为Query Cache 在内存中是以 HASH 结构来进行映射,HASH 算法基础就是组成 SQL 语句的字符,所以任何sql语句的改变重新Cache,这也是项目开发中要建立 SQL 语句书写规范的原因。

何时Cache

  • MySQL Query Cache 内容为 Select 的结果集,Cache 使用完整的 SQL 字符串做 Key,并区分大小写,空格等。即两个SQL必须完全一致才会让Cache命中。
  • prepared statement永远不会cache到结果,即使参数完全一样。据说在 5.1 之后会得到改善。
  • Where条件中如包含了某些函数永远不会被Cache,比如current_date、now等。
  • date 之类的函数如果返回是以小时或天级别的,最好先算出来再传进去。
    select * from foo where date1=current_date -- 不会被 cache
    select * from foo where date1='2008-12-30' -- 被cache, 正确的做法
  • 太大的result set不会被Cache (< query_cache_limit)

何时Invalidate

  • 一旦表数据进行任何一行的修改,基于该表相关cache立即全部失效。
  • 为什么不做聪明一点判断修改的是否Cache的内容?因为分析Cache内容太复杂,服务器需要追求最大的性能。

性能分析

Cache 未必所有场合总是会改善性能

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

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

大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

内存池使用

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

Query Cache 在提高数据库性能方面具有非常重要的作用。

其设定也非常简单,仅需要在配置文件写入两行: query_cache_type 和 query_cache _size,而且 MySQL 的 query cache 非常快!而且一旦命中,就直接发送给客户端,节约大量的 CPU 时间。

当然,非 SELECT 语句对缓冲是有影响的,它们可能使缓冲中的数据过期。一个 UPDATE 语句引起的部分表修改,将导致对该表所有的缓冲数据失效,这是 MySQL 为了平衡性能而没有采取的措施。因为,如果每次 UPDATE 需要检查修改的数据,然后撤出部分缓冲将导致代码的复杂度增加。

query_cache_type 0 代表不使用缓冲, 1 代表使用缓冲,2 代表根据需要使用。

设置 1 代表缓冲永远有效,如果不需要缓冲,就需要使用如下语句:

SELECT SQL_NO_CACHE * FROM my_table WHERE ...

如果设置为 2 ,需要开启缓冲,可以用如下语句:

SELECT SQL_CACHE * FROM my_table WHERE ...

用 SHOW STATUS 可以查看缓冲的情况:

mysql> show status like 'Qca%';
+-------------------------+----------+
| Variable_name | Value |
+-------------------------+----------+
| Qcache_queries_in_cache | 8 |
| Qcache_inserts | 545875 |
| Qcache_hits | 83951 |
| Qcache_lowmem_prunes | 0 |
| Qcache_not_cached | 2343256 |
| Qcache_free_memory | 33508248 |
| Qcache_free_blocks | 1 |
| Qcache_total_blocks | 18 |
+-------------------------+----------+
8 rows in set (0.00 sec)

如果需要计算命中率,需要知道服务器执行了多少 SELECT 语句:

mysql> show status like 'Com_sel%';
+---------------+---------+
| Variable_name | Value |
+---------------+---------+
| Com_select | 2889628 |
+---------------+---------+
1 row in set (0.01 sec)

在本例中, MySQL 命中了 2,889,628 条查询中的 83,951 条,而且 INSERT 语句只有 545,875 条。因此,它们两者的和和280万的总查询相比有很大差距,因此我们知道本例使用的缓冲类型是 2 。而在类型是 1 的例子中, Qcache_hits 的数值会远远大于 Com_select

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。
列表为空,暂无数据

关于作者

JSmiles

生命进入颠沛而奔忙的本质状态,并将以不断告别和相遇的陈旧方式继续下去。

0 文章
0 评论
84960 人气
更多

推荐作者

lorenzathorton8

文章 0 评论 0

Zero

文章 0 评论 0

萧瑟寒风

文章 0 评论 0

mylayout

文章 0 评论 0

tkewei

文章 0 评论 0

17818769742

文章 0 评论 0

    我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
    原文