MySQL如何进行查询缓存优化？查询缓存的配置与失效场景分析！-mysql教程-PHP中文网

答案是禁用查询缓存。MySQL查询缓存在5.7.20及以上版本已被废弃或移除，早期版本因全局锁和频繁失效导致性能下降，建议通过设置query_cache_type=0和query_cache_size=0禁用，并转向索引优化、应用层缓存等更高效策略。

mysql如何进行查询缓存优化？查询缓存的配置与失效场景分析！

MySQL的查询缓存，在大多数现代部署中，实际上更像是一个性能陷阱而非优化利器。简单来说，对于MySQL 5.7.20及以上版本，它已经被废弃甚至移除；而对于更老的版本，其带来的全局锁竞争和频繁的缓存失效，往往弊大于利。因此，查询缓存的“优化”核心，通常是理解其局限性，并考虑禁用它，转而采用更高效的缓存策略或直接优化SQL本身。

解决方案

要“优化”MySQL的查询缓存，最直接且推荐的方案是：禁用它。

这听起来有点反直觉，但事实就是如此。查询缓存的工作原理是，当一个SELECT语句执行时，如果其结果已经在缓存中，并且没有任何相关数据被修改，那么MySQL会直接返回缓存中的结果。问题在于，只要对任何一个表执行了INSERT、UPDATE、DELETE操作，所有与该表相关的查询缓存都会被标记为失效。在高并发、写操作频繁的系统中，这会导致缓存频繁失效，而维护和检查缓存的开销（特别是全局锁）反而会拖慢整个数据库的性能。

所以，如果你还在使用支持查询缓存的MySQL版本（如5.6或更早的5.7.x），请检查并禁用它。这可以通过修改

my.cnf

登录后复制

配置文件来实现：

[mysqld]
query_cache_type = 0
query_cache_size = 0

登录后复制

query_cache_type = 0

登录后复制

表示禁用查询缓存，

query_cache_size = 0

登录后复制

则释放其占用的内存。修改后需要重启MySQL服务才能生效。

MySQL查询缓存真的能提升性能吗？深入剖析其工作原理与潜在瓶颈

我个人在职业生涯中，确实见过不少团队尝试利用查询缓存来提升性能，结果却往往是适得其反。它的初衷是好的，通过避免重复执行相同的查询来减少CPU和IO开销。当一个查询进来，MySQL会先检查查询缓存。如果查询字符串（包括所有空格、注释、参数）与缓存中的某个条目完全匹配，并且涉及的表没有被修改过，那么结果就会直接返回。这听起来很美妙，对吧？

然而，现实是骨感的。它的主要瓶颈在于：

全局锁（Global Lock）：这是最致命的问题。在MySQL 5.6及更早版本中，查询缓存的维护需要一个全局锁。这意味着，当一个查询结果被写入缓存，或者一个缓存条目失效时，整个查询缓存都会被锁定。在高并发环境下，哪怕是短暂的锁定，也会导致大量查询排队等待，严重影响吞吐量。这就像一个只有一个收银员的超市，无论顾客多少，都得排队等。
缓存失效的频繁性与开销：前面提到，只要涉及的表有任何写操作（INSERT/UPDATE/DELETE），所有依赖该表的缓存都会失效。想象一下，一个热门商品表，每秒都有库存更新，那么所有查询该商品的缓存都会瞬间失效。而失效的过程本身也需要消耗CPU资源，进行哈希查找和内存清理。
内存管理开销：查询缓存需要额外的内存来存储查询结果。这些内存的分配和回收同样会带来开销。如果缓存的查询结果集很大，或者缓存命中率很低，那么这部分内存就白白浪费了，还增加了管理负担。
精确匹配要求：查询缓存要求查询字符串必须完全一致。即使是多一个空格，或者参数顺序不同，都会被认为是不同的查询。这使得缓存命中率在动态查询较多的应用中很难提高。

所以，我的观点是，除非你的应用场景非常特殊，比如读多写少到极致，且查询模式高度重复，否则查询缓存带来的负面影响远大于其潜在收益。

如何判断我的MySQL版本是否支持查询缓存？以及如何安全地禁用它？

判断你的MySQL版本是否支持查询缓存，或者说，是否仍然包含查询缓存模块，其实很简单。首先，你需要知道你正在使用的MySQL版本。可以通过连接到MySQL后执行

SELECT VERSION();

登录后复制

来查看。

MySQL 8.0及更高版本：查询缓存已经被完全移除。你甚至找不到相关的配置项，尝试设置它们会报错。所以，如果你是8.0+，恭喜你，你根本不用操心这个问题。
MySQL 5.7.20及更高版本（5.7系列）：查询缓存被标记为废弃（deprecated），虽然代码还在，但官方强烈建议不要使用。
MySQL 5.7.19及更早版本，以及5.6、5.5等版本：查询缓存是默认开启或可配置的。

要查看当前MySQL实例的查询缓存状态，可以执行：

SHOW VARIABLES LIKE 'query_cache_type';
SHOW VARIABLES LIKE 'query_cache_size';
SHOW STATUS LIKE 'Qcache%';

登录后复制

query_cache_type

登录后复制

的值可能是：

```
OFF
```
登录后复制
(或
```
0
```
登录后复制
)：查询缓存被禁用。
```
ON
```
登录后复制
(或
```
1
```
登录后复制
)：查询缓存被启用，但不会缓存以
```
SELECT SQL_NO_CACHE
```
登录后复制
开头的查询。
```
DEMAND
```
登录后复制
(或
```
2
```
登录后复制
)：查询缓存只对以
```
SELECT SQL_CACHE
```
登录后复制
开头的查询生效。

query_cache_size

登录后复制

显示了查询缓存分配的内存大小。如果为0，即使

query_cache_type

登录后复制

为

ON

登录后复制

，也无法实际缓存任何东西。

存了个图

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

查看详情

安全禁用查询缓存的步骤：

临时禁用（无需重启，但非持久化）：在MySQL客户端执行：
```
SET GLOBAL query_cache_type = OFF;
SET GLOBAL query_cache_size = 0;
```
登录后复制
这会立即停止缓存新的查询结果，并清除现有缓存。但重启MySQL服务后，配置会恢复到
```
my.cnf
```
登录后复制
中的设置。
永久禁用（推荐方式）：编辑你的
```
my.cnf
```
登录后复制
（或
```
my.ini
```
登录后复制
，取决于你的操作系统和安装方式）。通常在
```
/etc/my.cnf
```
登录后复制
、
```
/etc/mysql/my.cnf
```
登录后复制
或
```
/usr/local/mysql/etc/my.cnf
```
登录后复制
。在
```
[mysqld]
```
登录后复制
段下添加或修改以下两行：
```
[mysqld]
query_cache_type = 0
query_cache_size = 0
```
登录后复制
保存文件后，重启MySQL服务。这是确保设置持久生效的关键一步。重启后，再次使用
```
SHOW VARIABLES
```
登录后复制
命令验证。

禁用查询缓存通常是安全的，因为它避免了潜在的性能瓶颈，而不会影响数据库的正确性。

除了查询缓存，还有哪些更高效的MySQL查询优化策略？

既然查询缓存这个“银弹”常常是颗“铅弹”，那么我们应该把精力放在哪些地方呢？我的经验告诉我，真正的性能提升往往来自于多方面的综合优化，而不是单一的某个开关。

索引优化：这是最基础也是最重要的优化手段。一个好的索引能让查询速度提升几个数量级。
- 理解B-Tree索引：它如何帮助快速定位数据。
- 复合索引：考虑查询中
```
WHERE
```
  登录后复制
  子句的多个条件，创建覆盖这些条件的复合索引。注意索引列的顺序，通常将选择性最高的列放在前面。
- 覆盖索引：如果一个查询的所有列都能从索引中获取，而无需回表查询数据行，那么这个索引就是覆盖索引。这能极大减少IO操作。
- 避免全表扫描：
```
EXPLAIN
```
  登录后复制
  是你的好朋友，它能告诉你查询是否使用了索引，以及使用了哪种索引。
- 索引不是越多越好：每个索引都会增加写操作（INSERT/UPDATE/DELETE）的开销，因为每次写操作都需要更新索引。
SQL查询语句优化：
- *避免`SELECT `**：只选择你需要的列，减少网络传输和内存消耗。
- 优化
  WHERE
  登录后复制
  子句：避免在索引列上使用函数、进行类型转换、使用
```
OR
```
  登录后复制
  （除非所有条件都有索引）或
```
LIKE %keyword
```
  登录后复制
  （前缀匹配除外）。
- 优化
  JOIN
  登录后复制
  操作：确保
```
JOIN
```
  登录后复制
  条件上的列都有索引，选择合适的
```
JOIN
```
  登录后复制
  类型。
- 分页优化：对于大偏移量的分页（
```
LIMIT offset, count
```
  登录后复制
  ），可以考虑先用子查询或JOIN找到主键，再通过主键获取数据，例如：
```
SELECT * FROM table WHERE id IN (SELECT id FROM table ORDER BY id LIMIT 100000, 10)
```
  登录后复制
  。
应用层缓存：这是目前主流且高效的缓存策略。
- Redis/Memcached：将频繁访问但更新不频繁的数据（如配置信息、用户会话、热门商品列表等）缓存到这些内存数据库中。应用程序直接从缓存读取，只有缓存未命中或数据过期时才查询MySQL。
- ORM/框架自带缓存：许多Web框架或ORM（如Hibernate、MyBatis）都提供了二级缓存机制，可以在应用内部缓存对象。
数据库架构优化：
- 读写分离：将读操作分发到多个只读副本（Slave），主库（Master）只处理写操作。这能极大提升读并发能力。
- 分库分表（Sharding）：当单表数据量过大时，将数据分散到不同的数据库或表中，以减少单表压力。
- 硬件升级：虽然是最后的手段，但更快的CPU、更多的内存、SSD硬盘永远是提升性能的有效方式。
慢查询日志分析：定期开启慢查询日志（
```
slow_query_log = 1
```
登录后复制
，
```
long_query_time = 1
```
登录后复制
），分析那些执行时间过长的SQL语句。这是发现性能瓶颈最直接的途径。