mysqlmysql如何调整查询缓存参数-mysql教程-PHP中文网

MySQL 8.0已移除查询缓存，因其在高并发下存在锁竞争和频繁失效问题；建议通过应用层缓存、SQL优化、索引优化及InnoDB缓冲池等更高效手段提升性能。

mysqlmysql如何调整查询缓存参数

调整MySQL的查询缓存参数，主要涉及query_cache_size和query_cache_type这两个核心配置。虽然在某些特定场景下，查询缓存能提供性能增益，但随着MySQL版本的迭代，特别是8.0版本之后，查询缓存已经被移除，这本身就说明了其局限性和维护成本。因此，在考虑调整之前，我们更应该理解其工作原理及适用性。

解决方案

要调整MySQL的查询缓存参数，通常需要在MySQL的配置文件my.cnf（或my.ini）中进行修改，或者在运行时通过SQL命令动态调整。

1. 配置query_cache_size: 这个参数定义了查询缓存所能使用的总内存大小。单位可以是字节（默认），也可以是K、M、G。一个常见的配置示例是：

[mysqld]
query_cache_size = 64M

登录后复制

将query_cache_size设置为0意味着禁用查询缓存，即使query_cache_type被设置为ON。

2. 配置query_cache_type: 这个参数控制查询缓存的行为模式：

0 或 OFF：完全禁用查询缓存。
1 或 ON：启用查询缓存。所有不以SELECT SQL_NO_CACHE开头的查询都会被缓存，前提是它们满足缓存条件。
2 或 DEMAND：按需启用。只有以SELECT SQL_CACHE开头的查询才会被缓存。

示例配置：

[mysqld]
query_cache_type = ON

登录后复制

3. 动态调整（仅限query_cache_type和query_cache_size在非0时）： 你可以在MySQL运行时使用SET GLOBAL命令来修改这两个参数，但这些更改在MySQL服务重启后会失效。

SET GLOBAL query_cache_size = 67108864; -- 设置为64MB
SET GLOBAL query_cache_type = ON;

登录后复制

要查看当前查询缓存的状态和配置，可以使用：

SHOW VARIABLES LIKE 'query_cache%';
SHOW STATUS LIKE 'Qcache%';

登录后复制

这些状态变量能告诉你缓存的命中率、碎片化程度等关键信息。

在我看来，如果你还在使用MySQL 5.7或更早版本，并且面临特定的读密集型、数据不常变化的场景，那么调整查询缓存可能还有点意义。但说实话，在大多数现代应用中，它的负面影响往往大于正面。

查询缓存真的能提升MySQL性能吗？

这是一个我经常被问到的问题，我的答案通常是：看情况，但多数时候不推荐将其作为首选优化手段。

查询缓存的初衷是好的，它旨在通过存储SELECT查询的结果集，当相同的查询再次到来时，直接返回缓存结果，从而避免重新执行复杂的查询逻辑、访问磁盘。对于那些读多写少、数据相对静态的业务场景，比如一些历史数据报表、不常更新的配置信息查询，查询缓存确实能在理论上带来显著的性能提升，因为CPU和I/O开销都大大降低了。

存了个图

视频图片解析/字幕/剪辑，视频高清保存/图片源图提取

查看详情

然而，它的缺点也同样明显，甚至可以说是致命的：

失效机制过于粗糙： 只要缓存中的任何一个表发生数据修改（INSERT, UPDATE, DELETE, TRUNCATE, ALTER TABLE等），所有涉及到这个表的查询缓存条目都会被立刻标记为失效。这意味着在高写入负载的系统中，缓存几乎是瞬间失效，大部分时间都花在了失效和重新缓存上，而非提供服务。
全局锁竞争（Mutex Contention）： 在MySQL 5.6及更早版本中，查询缓存的内部管理需要一个全局锁。这意味着在高并发环境下，即使是不同的查询，在访问或更新查询缓存时也可能因为争抢这个锁而串行化，导致性能急剧下降。虽然5.7版本有所改进，但核心问题依然存在。
内存管理开销： 缓存的碎片化、内存分配和回收都会带来额外的开销。
缓存命中率难以保障： 即使是微小的查询差异（例如WHERE子句中的空格、注释、参数顺序），都会导致缓存不命中。

所以，在我个人的经验里，除非你对自己的业务场景有极其深入的了解，并且能确定它完全符合查询缓存的“理想”工作环境，否则开启查询缓存，往往会带来意想不到的性能瓶颈，尤其是在高并发或高写入的生产环境中。MySQL 8.0直接将其移除，也印证了社区和官方对其有效性的质疑。

在MySQL 8.0之后，我该如何处理查询缓存？

如果你正在使用MySQL 8.0或更高版本，那么关于查询缓存的讨论就可以直接停止了。因为它已经不存在了。 MySQL官方决定在8.0版本中彻底移除查询缓存功能，理由正是它在现代数据库工作负载下的低效和维护成本。

这意味着，你不再需要关注query_cache_size或query_cache_type这些参数。当你尝试查询它们时，你会发现它们已经被移除了。

那么，当查询缓存不再可用时，我们应该如何实现类似的性能优化呢？这其实是好事，因为这迫使我们去拥抱更健壮、更可控的缓存策略：

应用层缓存： 这是最常见且推荐的做法。使用像Redis、Memcached这样的内存数据库来缓存查询结果。应用可以根据业务逻辑精确控制缓存的生命周期、失效策略，避免了MySQL查询缓存的粗粒度失效问题。
代理层缓存： 比如使用ProxySQL、MaxScale等数据库中间件，它们可以在代理层实现查询结果的缓存。这种方式介于应用层和数据库层之间，可以对数据库流量进行更细致的控制和缓存。
优化SQL查询本身： 这才是治本之策。确保你的SQL语句高效，索引设计合理，避免全表扫描，减少不必要的JOIN操作。
数据库内部的其他缓存机制： MySQL本身还有很多高效的缓存机制，例如InnoDB缓冲池（innodb_buffer_pool_size），它缓存了数据页和索引页，这比缓存整个查询结果集更底层、更高效。
硬件升级： 增加内存、使用SSD等高性能存储，提升CPU性能，这些都能直接提升数据库的处理能力。