mysql安装后如何配置查询缓存-mysql教程-PHP中文网

答案：MySQL查询缓存需配置my.cnf或my.ini中的query_cache_type、query_cache_size等参数，但该功能在MySQL 8.0中已被移除，因存在锁竞争、内存碎片等问题，建议使用Redis等应用层缓存替代。

mysql安装后如何配置查询缓存

MySQL安装后要配置查询缓存，核心就是修改其主配置文件

my.cnf

登录后复制

（或

my.ini

登录后复制

，取决于你的操作系统），找到并调整或新增

[mysqld]

登录后复制

段落下的相关参数。简单来说，你需要明确开启查询缓存功能，并为其分配合适的内存空间。但话说回来，这功能在新版MySQL中已经逐渐被废弃，甚至完全移除了，所以配置前，最好先搞清楚你使用的MySQL版本。

在大多数情况下，配置查询缓存主要涉及以下几个参数：

解决方案

配置MySQL查询缓存，你需要编辑MySQL的配置文件。这个文件通常位于

/etc/mysql/my.cnf

登录后复制

、

/etc/my.cnf

登录后复制

或

/usr/local/mysql/etc/my.cnf

登录后复制

（Linux/Unix），或者在Windows上是MySQL安装目录下的

my.ini

登录后复制

。

定位配置文件： 你可以通过
```
mysql --help | grep "Default options"
```
登录后复制
来查找配置文件的默认路径。
编辑配置文件： 使用文本编辑器打开找到的配置文件。在
```
[mysqld]
```
登录后复制
配置段下，添加或修改以下参数：
```
[mysqld]
query_cache_type = 1
query_cache_size = 64M
query_cache_limit = 1M
```
登录后复制
- ```
query_cache_type
```
  登录后复制
  ：
  - ```
  0
```
  登录后复制
  或
```
  OFF
```
  登录后复制
  ：禁用查询缓存。
- ```
1
```
    登录后复制
    或
```
ON
```
    登录后复制
    ：启用查询缓存，但可以通过
```
SELECT SQL_NO_CACHE ...
```
    登录后复制
    来跳过缓存。
  - ```
  2
```
  登录后复制
  或
```
  DEMAND
```
  登录后复制
  ：只有当查询语句显式使用
```
  SELECT SQL_CACHE ...
```
  登录后复制
  时才缓存。我个人觉得
```
  DEMAND
```
  登录后复制
  模式在某些特定场景下可能有点用，但大多数时候，如果决定用，直接
```
  ON
```
  登录后复制
  更省心。
- ```
query_cache_size
```
  登录后复制
  ：这是分配给查询缓存的总内存大小。单位可以是
```
K
```
  登录后复制
  、
```
M
```
  登录后复制
  或
```
G
```
  登录后复制
  。这个值设多大是个学问，太小没效果，太大又可能导致锁竞争和内存碎片，反而拖慢性能。我见过不少人一上来就给个几百兆，结果发现服务器CPU负载更高了，因为MySQL花太多时间在管理这个大缓存上。我的建议是，从一个相对保守的值开始，比如
```
32M
```
  登录后复制
  或
```
64M
```
  登录后复制
  ，然后观察效果。
- ```
query_cache_limit
```
  登录后复制
  ：单个查询结果能被缓存的最大大小。如果一个查询结果超过这个限制，它就不会被缓存。这参数挺重要的，可以避免缓存那些特别大的结果集，因为这些结果集通常不常被重复查询，而且缓存它们会占用大量内存，挤占了其他更小、更频繁查询的空间。
重启MySQL服务： 修改配置文件后，必须重启MySQL服务才能使配置生效。
- Linux:
```
sudo systemctl restart mysql
```
  登录后复制
  或
```
sudo service mysql restart
```
  登录后复制
- Windows: 通过服务管理器重启MySQL服务。
重启后，可以通过
```
SHOW VARIABLES LIKE 'query_cache%';
```
登录后复制
来确认配置是否生效。

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

这是一个老生常谈的问题，也是我个人在做数据库优化时，往往会第一个跳过考虑的选项，尤其是对于现代的Web应用。简单来说，它可能提升性能，但更多时候，它带来的负面影响可能比正面收益更大，或者说，它的适用场景非常有限。

查询缓存的工作原理是，当一个查询语句执行完毕，并且其结果符合缓存条件时，MySQL会将这个查询语句和结果存储起来。下次如果遇到完全相同的查询语句（包括大小写、空格、注释等都必须完全一致），并且涉及到的表数据没有发生任何变化，MySQL就会直接返回缓存中的结果，而不需要再次解析、优化、执行查询。听起来很美对吧？

问题就出在“涉及到的表数据没有发生任何变化”这一点上。只要任何被缓存查询所涉及的表发生任何数据修改（

INSERT

登录后复制

UPDATE

登录后复制

DELETE

登录后复制

TRUNCATE TABLE

登录后复制

ALTER TABLE

登录后复制

DROP TABLE

登录后复制

等），所有与该表相关的缓存条目都会被立即清除。这意味着，在一个写操作频繁的数据库中，查询缓存的命中率会非常低，甚至接近于零。缓存还没热起来，就被清空了。这时候，MySQL花在管理缓存、检查缓存有效性上的开销，反而成了额外的负担，导致性能下降。

所以，查询缓存适合的场景是：

读多写少：数据库以读取操作为主，写入操作非常少。
查询重复率高：有大量完全相同的查询反复执行。
结果集稳定：查询结果集大小适中，且变化不频繁。

如果你的应用场景符合这三点，那可以尝试配置。但如果不是，我建议你把精力放在优化SQL语句、建立合适的索引、或者考虑更高级的缓存方案（比如Redis、Memcached）上。这些往往能带来更稳定、更显著的性能提升。

如何监控MySQL查询缓存的命中率与使用情况？

配置完查询缓存，最重要的就是观察它到底有没有发挥作用。光配置不监控，那是盲人摸象。我们可以通过

SHOW STATUS

登录后复制

命令来查看查询缓存的各项统计指标。

在MySQL客户端中执行：

存了个图

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

查看详情

SHOW STATUS LIKE 'Qcache%';

登录后复制

你会看到一系列以

Qcache_

登录后复制

开头的状态变量，其中几个关键的你需要重点关注：

```
Qcache_hits
```
登录后复制
：查询缓存命中的次数。这个值越高越好，表明你的缓存正在有效工作。
```
Qcache_inserts
```
登录后复制
：添加到查询缓存中的查询结果数量。
```
Qcache_not_cached
```
登录后复制
：没有被缓存的查询数量。这可能是因为
```
query_cache_type
```
登录后复制
设置、查询语句使用了
```
SQL_NO_CACHE
```
登录后复制
、查询结果太大超过
```
query_cache_limit
```
登录后复制
，或者查询涉及临时表等原因。
```
Qcache_lowmem_prunes
```
登录后复制
：由于内存不足而被清除的查询数量。如果这个值很高，说明
```
query_cache_size
```
登录后复制
可能太小了，或者缓存管理效率不高。这通常是个警示信号，表明缓存空间不足以容纳频繁的查询。
```
Qcache_free_memory
```
登录后复制
：查询缓存中剩余的可用内存大小。
```
Qcache_queries_in_cache
```
登录后复制
：当前缓存中的查询数量。
```
Qcache_total_blocks
```
登录后复制
：查询缓存中总的块数量。

如何判断命中率？

一个简单的命中率计算公式是：

Qcache_hits / (Qcache_hits + Qcache_inserts)

登录后复制

。如果这个比率长期低于某个阈值（比如0.2或0.3），那查询缓存的效益就非常可疑了。我个人觉得，如果命中率不高，还不如关掉它，把这些资源让给其他更有效的优化手段。

监控这些指标，最好是周期性地进行，比如每隔一段时间（几分钟或几小时）记录一次，然后分析其变化趋势。这样才能真正了解查询缓存在你实际应用中的表现。

为什么新版MySQL中查询缓存被移除了？我们该如何替代它？

这其实是查询缓存最“致命”的问题，也是我前面提到，它往往不是我的首选优化方案的原因——它在MySQL 5.7.20中被弃用，并在MySQL 8.0中被完全移除。这个决策并非空穴来风，而是基于其固有的设计缺陷和在现代数据库负载下的低效表现。

被移除的原因主要有以下几点：

锁竞争问题： 整个查询缓存是由一个全局锁（
```
query_cache_mutex
```
登录后复制
）来保护的。在高并发场景下，无论是读取缓存、写入缓存还是清除缓存，都需要获取这个全局锁。这就导致了严重的锁竞争，反而成了性能瓶颈，尤其是CPU核心数多的服务器上，这个问题尤为突出。
内存碎片化： 查询缓存的内存管理机制效率不高，容易产生大量的内存碎片。当缓存空间不足时，MySQL需要花费额外的时间来整理碎片，这又进一步加剧了性能问题。
失效机制过于粗粒度： 前面提到了，只要涉及到的表有任何数据变动，所有相关的缓存都会被清空。这种“大刀阔斧”的失效机制，在写操作稍频繁的系统中，导致缓存几乎无法有效利用。
与优化器冲突： 查询缓存是在解析器和优化器之后才介入的。这意味着，即使命中了缓存，查询本身还是需要经过解析的。而且，它无法与MySQL新的优化技术（如查询重写、自适应哈希索引等）很好地协同工作。

替代方案：

既然查询缓存已经退出历史舞台，那我们应该如何实现类似的加速效果呢？

应用层缓存（Redis/Memcached）： 这是最常见也是最有效的替代方案。将频繁访问、变化不大的数据或查询结果缓存到应用层的缓存服务中（如Redis或Memcached）。应用在查询数据时，先从缓存中获取，如果缓存中没有，再去数据库查询，并将结果写入缓存。这种方式的优点是：
- 粒度更细： 可以根据业务需求，精确控制缓存哪些数据、缓存多久。
- 高并发： Redis/Memcached本身就是为高并发设计的，性能远超MySQL查询缓存。
- 分布式： 易于扩展，可以构建分布式缓存集群。
- 灵活性： 可以缓存各种类型的数据，不仅仅是SQL查询结果。
SQL语句和索引优化： 这永远是数据库优化的基石。一个设计良好、索引健全的数据库，其查询效率本身就很高，很多时候根本不需要额外的缓存层。
- 分析慢查询： 使用
```
EXPLAIN
```
  登录后复制
  分析慢查询语句，理解其执行计划。
- 创建合适索引： 根据查询条件和排序规则，创建复合索引或覆盖索引。
- 避免全表扫描： 优化SQL，尽量让查询能走索引。
数据库连接池： 虽然不是直接的查询缓存，但一个配置合理的连接池可以显著减少连接建立和关闭的开销，提高数据库的整体响应速度。
物化视图（Materialized Views）： 对于某些复杂的、耗时较长的报表查询，可以考虑在数据库层面创建物化视图。物化视图会预先计算并存储查询结果，当查询物化视图时，可以直接获取结果，无需再次执行底层查询。当然，这需要数据库本身支持，并且需要考虑视图的刷新策略。