MYSQL 的Query Cache


MYSQL的Query Cache

当你的数据库打开了Query Cache(简称QC)功能后,数据库在执行SELECT语句时,会将其结果放到QC中,当下一次处理同样的SELECT请求时,数据库就会从QC取得结果,而不需要去数据表中查询。

Query-Cache-2

在这个“Cache为王”的时代,我们总是通过不同的方式去缓存我们的结果从而提高响应效率,但一个缓存机制是否有效,效果如何,却是一个需要好好思考的问题。在MySQL中的Query Cache就是一个适用较少情况的缓存机制。在上图中,如果缓存命中率非常高的话,有测试表明在极端情况下可以提高效率238%[1]。但实际情况如何?Query Cache有如下规则,如果数据表被更改,那么和这个数据表相关的全部Cache全部都会无效,并删除之。这里“数据表更改”包括: INSERTUPDATEDELETETRUNCATEALTER TABLEDROP TABLE, or DROP DATABASE等。举个例子,如果数据表posts访问频繁,那么意味着它的很多数据会被QC缓存起来,但是每一次posts数据表的更新,无论更新是不是影响到了cache的数据,都会将全部和posts表相关的cache清除。如果你的数据表更新频繁的话,那么Query Cache将会成为系统的负担。有实验表明,糟糕时,QC会降低系统13%[1]的处理能力。

如果你的应用对数据库的更新很少,那么QC将会作用显著。比较典型的如博客系统,一般博客更新相对较慢,数据表相对稳定不变,这时候QC的作用会比较明显。

再如,一个更新频繁的BBS系统。下面是一个实际运行的论坛数据库的状态参数:

QCache_hit 5280438
QCache_insert 8008948
Qcache_not_cache 95372
Com select 8104159

可以看到,数据库一共往QC中写入了约800W次缓存,但是实际命中的只有约500W次。也就是说,每一个缓存的使用率约为0.66次。很难说,该缓存的作用是否大于QC系统所带来的开销。但是有一点是很肯定的,QC缓存的作用是很微小的,如果应用层能够实现缓存,将可以忽略QC的效果。

————-下面是关于QC的一些其他细节—————–

一、Query Cache相关参数:

  • query_cache_size QC占用空间大小,通过将其设置为0关闭QC功能
  • query_cache_type 0表示关闭QC;1表示正常缓存;2表示SQL_CACHE才缓存
  • query_cache_limit 最大缓存结果集
  • query_cache_min_res_unit 手册上说,QC会按照这个值分配缓存block的大小。
  • Qcache_lowmem_prunes 这是一个状态变量(show status),当缓存空间不够需要释放旧的缓存时,该值会自增。

二、Query Cache观察:

CREATE TABLE t1(id INT,var1 varchar(10));
	//Com_select:8	Qcache_hits:1
INSERT INTO t1 VALUES(1,’WWW’);
	//Com_select:8	Qcache_hits:1
SELECT * FROM t1 WHERE id=1;
	//Com_select:9	Qcache_hits:1
SELECT * FROM t1 WHERE id=1;
	//Com_select:9	Qcache_hits:2 Qcache_queries_in_cache:1
INSERT INTO t1 VALUES(2,’RRRR’);
	//Com_select:9	Qcache_hits:2 Qcache_queries_in_cache:0
SELECT * FROM t1 WHERE id=1; //INSERT后Cache失效
	//Com_select:10  Qcache_hits:2 Qcache_queries_in_cache:1

参考:

  1. http://dev.mysql.com/doc/refman/5.0/en/query-cache.html
  2. http://dev.mysql.com/doc/refman/5.0/en/server-system-variables.html
  3. http://www.mysqlperformanceblog.com/2006/07/27/mysql-query-cache/
原文地址: 

<think>我们正在讨论MySQL的查询计划缓存(Query Plan Cache)。根据用户的问题,我们需要提供Query Plan Cache的定义和相关信息。需要注意的是,MySQL中并没有一个名为“Query Plan Cache”的独立缓存,但通常我们提到的查询缓存(Query Cache)和准备语句的缓存(Prepared Statement Cache)与查询计划相关。 然而,在MySQL中,查询缓存(Query Cache)缓存的是整个SELECT查询的结果集,而不是查询计划本身。而对于查询计划缓存,实际上在MySQL 8.0之前,存储过程有查询计划缓存,但对于一般的SQL语句,MySQL并不会缓存查询计划(除了准备语句)。 在MySQL 8.0中,引入了执行计划缓存(Execution Plan Cache)用于准备好的语句(prepared statements)。所以,用户可能指的是这个。 因此,我们将重点介绍MySQL中的执行计划缓存(用于准备语句)以及可能相关的查询缓存(但注意,查询缓存已在MySQL 8.0中被移除)。 由于用户的问题是关于“Query Plan Cache”,我们主要讨论执行计划缓存(针对准备语句)。 定义: 执行计划缓存(Execution Plan Cache)是MySQL中用于存储预处理语句(prepared statements)的执行计划的一种缓存机制。当相同的预处理语句再次执行时,MySQL可以重用之前编译好的执行计划,从而跳过优化和编译阶段,提高执行效率。 详细介绍: 1. 缓存对象:执行计划缓存针对的是预处理语句(Prepared Statements)。预处理语句是通过`PREPARE ... FROM`创建的,或者通过客户端驱动程序(如Connector/J、Connector/Python等)以二进制协议发送的语句(通常使用参数化查询)。 2. 工作原理: - 当预处理语句第一次执行时,MySQL会进行解析、优化,并生成执行计划,然后将执行计划缓存起来。 - 后续执行相同的预处理语句时,MySQL会直接使用缓存的执行计划,只需将参数替换即可执行,从而节省了优化时间。 3. 缓存管理: - 缓存大小由系统变量`cached_prepared_statements`控制(在MySQL 5.7中,这个变量是`max_prepared_stmt_count`,但在MySQL 8.0中,执行计划缓存的管理有所变化)。 - 在MySQL 8.0中,执行计划缓存的大小由系统变量`prepared_statement_cache_size`(会话级别)和`prepared_statement_cache_size_limit`(全局限制)控制。 - 缓存采用LRU(最近最少使用)策略进行管理。 4. 注意事项: - 执行计划缓存只对预处理语句有效,普通的查询语句不会缓存执行计划。 - 当表结构发生变化(如ALTER TABLE)或数据分布发生显著变化(导致统计信息更新)时,相关的执行计划会被自动从缓存中移除,以确保执行计划的正确性。 - 执行计划缓存是会话级别的,但全局参数可以限制总的缓存大小。 5. 与查询缓存的区别: - 查询缓存(Query Cache)缓存的是查询结果集,而执行计划缓存缓存的是执行计划(即如何执行查询的步骤)。 - 查询缓存在MySQL 8.0中被移除,而执行计划缓存仍然存在。 6. 相关系统变量(以MySQL 8.0为例): - `prepared_statement_cache_size`: 每个会话缓存的预处理语句数量(默认值根据文档可能有所不同,通常为256)。 - `prepared_statement_cache_size_limit`: 全局限制,防止所有会话的总缓存占用过多内存(默认值通常为2MB,但实际存储的是计划,不是结果)。 7. 监控: - 可以通过`SHOW STATUS LIKE 'Com_prepare_sql'`和`SHOW STATUS LIKE 'Com_execute_sql'`来查看预处理语句的准备工作次数和执行次数。 - 状态变量`Prepared_stmt_count`显示当前系统中的预处理语句数量(包括缓存的)。 需要注意的是,在MySQL 5.7及之前,执行计划缓存的行为和配置有所不同。 由于用户引用的内容中提到了EXPLAIN和SHOW PROCESSLIST等,这些虽然与查询计划有关,但不是直接针对执行计划缓存的。因此,我们主要围绕上述内容回答。 根据引用[1]中的内容,EXPLAIN只能解释SELECT操作,而且部分统计信息是估算的,这也说明了为什么执行计划缓存很重要,因为重复的预处理语句可以避免重复优化。 现在,我们将回答组织如下: </think>### MySQL 查询计划缓存(Query Plan Cache)的定义与介绍 #### 定义 MySQL **查询计划缓存**(Query Plan Cache)是一种优化机制,用于存储已解析和优化后的SQL语句执行计划。当相同的SQL语句重复执行时,MySQL可直接重用缓存的执行计划,**跳过语法解析、语义检查和优化器计算等步骤**,从而显著提升查询性能。该缓存主要针对**预处理语句(Prepared Statements)**。 #### 核心特性 1. **缓存对象** - 仅缓存预处理语句(通过`PREPARE`创建或应用程序参数化查询)的优化执行计划。 - 普通即时查询(Ad-hoc Query)**不缓存**执行计划。 2. **缓存生命周期** - 会话级缓存:默认绑定到客户端会话,会话结束时自动释放。 - 全局管理:通过参数控制全局缓存总量(如`prepared_statement_cache_size`)。 3. **缓存失效机制** 当以下操作发生时,相关执行计划自动失效: - 表结构变更(`ALTER TABLE`) - 索引添加/删除 - 统计信息更新(如`ANALYZE TABLE`) - 数据量剧烈变化(导致优化器重新选择索引)[^1] 4. **性能提升原理** ![执行计划缓存对比](https://www.mysqltutorial.org/wp-content/uploads/2018/11/MySQL-Prepared-Statement-Execution-Plan-Cache.png) 首次执行需完整流程(解析→优化→执行),后续执行**直接跳至执行阶段**。 #### 相关配置参数 | 参数名 | 作用 | 默认值 | |---------------------------------|----------------------------------------------------------------------|---------------| | `prepared_statement_cache_size` | 单个会话最大缓存的预处理语句数量 | 256(条) | | `performance_schema_max_prepared` | 监控缓存的性能模式指标数量 | 动态调整 | | `max_prepared_stmt_count` | 全局最大预处理语句数量(含缓存和活跃语句) | 16,382 | #### 局限性 1. **不适用于即时查询** 如`SELECT * FROM users WHERE id=1;`这类非参数化查询无法利用缓存[^1]。 2. **内存开销** 每个缓存的执行计划约占用10-100KB内存,需权衡性能与资源消耗。 3. **动态环境适应性差** 数据分布频繁变化时,缓存可能保留非最优计划,需手动清除(`DEALLOCATE PREPARE`)[^1]。 #### 操作示例 ```sql -- 创建预处理语句(自动缓存执行计划) PREPARE user_query FROM 'SELECT * FROM users WHERE age > ?'; -- 首次执行(解析+优化+执行) SET @age_threshold = 30; EXECUTE user_query USING @age_threshold; -- 后续执行(直接使用缓存计划) SET @age_threshold = 40; EXECUTE user_query USING @age_threshold; -- 手动释放缓存 DEALLOCATE PREPARE user_query; ``` #### 监控方法 ```sql -- 查看缓存命中率(Com_stmt_execute vs Com_stmt_prepare) SHOW GLOBAL STATUS LIKE 'Com_stmt%'; ``` - **高缓存命中率标志**:`Com_stmt_execute` >> `Com_stmt_prepare` ---
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值