MySQL 8.0移除查询缓存因其在高并发下存在锁竞争、缓存失效开销大、精确匹配限制多等问题，反而影响性能；开发者应转向应用层缓存（如Redis）、SQL优化、读写分离、分库分表等更高效、可控的现代优化策略。
SQL查询缓存，说白了，就是数据库为了偷懒，把之前执行过的查询结果记下来，下次再遇到一模一样的查询，就直接把存好的结果丢给你，省去了重新执行查询的开销。它旨在提升读取密集型应用的性能，减少数据库的CPU和I/O负载。然而，它的有效性并非一劳永逸，尤其在现代数据库版本中，其角色和作用已经发生了根本性变化，甚至被移除，因此理解其配置与优化，更多的是理解其局限性和替代方案。
查询缓存的工作原理其实挺直观的：当一个查询被执行后，它的文本和结果集会被存储起来。下次，如果完全相同的查询（包括大小写、空格甚至注释）再次到来，数据库会直接从缓存中取出结果。这听起来很美好，尤其对于那些读多写少的应用，简直是性能的灵丹妙药。但现实往往没那么简单，它的“完全相同”要求，以及任何数据变更都会导致相关缓存失效的机制，让它的实际效益大打折扣。所以，与其说“利用”，不如说“理解其局限性，并在特定场景下审慎评估”。在很多情况下，它的维护开销甚至可能超过它带来的收益，尤其是在高并发写入的环境下。
MySQL查询缓存的关键配置参数有哪些？如何进行有效设置？
要配置MySQL查询缓存，主要涉及几个核心参数：
query_cache_type
、
query_cache_size
和
query_cache_limit
。
query_cache_type
：这个参数决定了查询缓存的行为模式。
0 (OFF)
：完全禁用查询缓存。这是MySQL 8.0及以后版本的默认行为，因为该功能已被移除。
1 (ON)
：开启查询缓存，但只有那些不带
SQL_NO_CACHE
提示的
SELECT
语句才会被缓存。
2 (DEMAND)
：开启查询缓存，但只有那些明确带有
SQL_CACHE
提示的
SELECT
语句才会被缓存。个人觉得，如果非要用，
DEMAND
模式相对更可控一些，因为它把选择权交给了开发者。
query_cache_size
：这个参数定义了查询缓存可以使用的总内存大小。单位通常是字节，但也可以用K、M、G等后缀。
设置过小，缓存很快就会满，导致频繁的缓存失效和替换，效果不明显。设置过大，可能会占用过多内存，甚至导致操作系统层面的内存交换（swap），反而拖慢系统。同时，管理大块内存的开销也会增加。一个经验法则可能是，对于那些真的需要它的老系统，可以从几十MB开始尝试，比如
64M
或
128M
，然后根据实际负载和缓存命中率进行调整。
query_cache_limit
：这个参数限制了单个查询结果集可以占用的最大内存大小。
如果一个查询的结果集超过了这个限制，它就不会被缓存。这有助于防止某个巨大的查询结果独占整个缓存空间。
如何设置？
你可以在
my.cnf
（或
my.ini
）配置文件中进行设置，例如：
[mysqld]query_cache_type = 2query_cache_size = 64Mquery_cache_limit = 1M
修改后需要重启MySQL服务才能生效。对于运行中的MySQL实例，也可以使用
SET GLOBAL
命令动态修改，但这种修改在服务重启后会失效：
LibLibAI
国内领先的AI创意平台，以海量模型、低门槛操作与“创作-分享-商业化”生态，让小白与专业创作者都能高效实现图文乃至视频创意表达。
159 查看详情 
SET GLOBAL query_cache_type = 2;SET GLOBAL query_cache_size = 67108864; -- 64MSET GLOBAL query_cache_limit = 1048576; -- 1M
不过，说句实在话，对于现代的MySQL版本（尤其是5.7之后），我个人倾向于直接关闭它。因为它的维护成本和潜在的性能瓶颈，往往会抵消它带来的好处。
为什么说MySQL 8.0移除了查询缓存？这对性能优化意味着什么？
MySQL在8.0版本中彻底移除了查询缓存功能，这并非偶然，而是深思熟虑后的决定。背后的主要原因在于查询缓存存在固有的设计缺陷，在高并发、数据频繁更新的场景下，其弊端远大于益处。
移除的核心原因：
高并发下的锁竞争（Mutex Contention）：查询缓存的实现需要一个全局锁来管理缓存的写入、查找和失效。在高并发读写混合的场景下，这个全局锁会成为严重的性能瓶颈。即使是读取操作，也需要获取锁来检查缓存，而任何对表的写入操作（
INSERT
,
UPDATE
,
DELETE
）都会导致所有与该表相关的缓存条目失效，这个失效过程同样需要获取锁，并可能导致其他查询阻塞，从而极大地降低了系统的吞吐量。缓存失效的开销：数据更新是常态，只要表中的数据发生变化，所有依赖于该表的缓存条目都需要被标记为失效。这个失效过程本身会消耗CPU资源，并且在大型缓存中，查找并标记失效的开销并不小。如果更新频繁，缓存几乎总是处于失效状态，那么它就成了摆设，甚至负优化。精确匹配的局限性：查询缓存要求查询文本必须完全一致，包括空格、注释甚至参数值。这意味着
SELECT * FROM users WHERE id = 1;
和
SELECT * FROM users WHERE id = 2;
是两个不同的缓存条目，而
SELECT * FROM users WHERE id = 1 /* comment */;
又是一个新的。这使得缓存的命中率很难提升，尤其是在动态SQL和参数化查询盛行的现代应用中。难以扩展：查询缓存是服务器层面的一个全局组件，无法很好地与分布式架构或读写分离策略结合。它是一个单点缓存，难以横向扩展。
对性能优化意味着什么？
MySQL 8.0移除查询缓存，无疑向开发者传递了一个明确的信号：不要再依赖数据库自带的查询缓存进行性能优化了。 这意味着：
开发者需要转向更成熟、更可控的缓存策略：比如应用层缓存（Redis, Memcached）、CDN缓存等。这些缓存方案通常具有更好的扩展性、更灵活的失效策略，并且可以根据业务需求进行精细化控制。更加注重SQL本身的优化：索引设计、查询语句的编写、数据库结构优化等基础工作变得更加重要。没有了“自动缓存”的幻想，开发者必须回归到SQL优化的本质。推动架构设计向读写分离、分布式演进：通过读写分离来分散读取压力，通过分库分表来解决单点性能瓶颈，这些架构层面的优化比一个简单的查询缓存要有效得多。减少了不必要的复杂性和维护成本：虽然查询缓存理论上能带来好处，但在实际运维中，它往往是一个难以调优、容易出问题的组件。移除它，反而简化了数据库的内部机制，让数据库内核可以专注于更核心的优化。
总的来说，移除查询缓存是MySQL走向现代化、高性能、高可用架构的重要一步。它迫使我们放弃一个“看起来很美”但实际效果不佳的特性，转而拥抱更健壮、更可扩展的优化实践。
除了查询缓存，还有哪些更现代、更有效的SQL查询优化策略？
既然数据库自带的查询缓存已经“过时”甚至被移除，那么作为开发者和架构师，我们自然需要寻求更现代、更有效的SQL查询优化策略。这些策略往往更加灵活、可控，且能更好地适应高并发、大数据量的场景。
应用层缓存（Application-Level Caching）：这是最常用且效果显著的替代方案。通过在应用代码层面集成缓存系统（如Redis、Memcached），将那些查询频率高、数据变化不频繁的查询结果缓存起来。
优点：缓存粒度可以更细，可以缓存整个页面、API响应，或者特定查询的结果集。缓存失效策略（TTL、LRU等）灵活可控，且缓存系统本身通常具有高可用和分布式特性。实现方式：在执行数据库查询前，先检查缓存中是否存在所需数据；如果存在，直接从缓存返回；如果不存在，执行数据库查询，并将结果存入缓存。示例场景：商品详情页、用户信息、配置数据等。
优化SQL查询语句和索引：这是数据库性能优化的基石，也是最基本、最重要的一环。
合理设计索引：根据查询模式（
WHERE
子句、
JOIN
条件、
ORDER BY
、
GROUP BY
）创建合适的索引。使用
EXPLAIN
命令分析查询计划，确保索引被有效利用。避免全表扫描：尽量让查询走索引。优化
JOIN
操作：选择正确的
JOIN
类型，确保
JOIN
字段有索引，并且
JOIN
顺序合理。*避免 `SELECT `**：只选择需要的列，减少数据传输量。限制结果集大小：使用
LIMIT
关键字避免返回过多不必要的数据。优化子查询：在某些情况下，子查询可以通过
JOIN
或
EXISTS
优化。
读写分离（Read-Write Splitting）：对于读操作远多于写操作的应用，可以将读请求分发到多个只读副本（Read Replicas），从而分散数据库的读取压力，提高系统的吞吐量和可用性。
优点：显著提升读操作的扩展性，减轻主库压力，提高整体性能。实现方式：主库负责所有写操作，并将数据同步到多个从库。应用层通过路由层或配置，将写请求发送给主库，读请求发送给从库。
数据库分片（Sharding）或分区（Partitioning）：当单个数据库实例无法承载海量数据或高并发请求时，可以考虑将数据水平拆分到多个独立的数据库实例（分片），或在单个表内进行垂直拆分（分区）。
优点：提高数据库的存储容量和处理能力，减少单个查询扫描的数据量，从而提升查询性能。实现方式：根据某个键（如用户ID、时间范围）将数据分散到不同的物理或逻辑单元。
物化视图（Materialized Views）或预聚合：对于涉及复杂计算、聚合或多表连接的报表类查询，可以创建物化视图或预先计算好结果，将其存储在单独的表中。
优点：避免每次查询都进行昂贵的计算，显著提升复杂查询的响应速度。实现方式：定期（如每小时、每天）运行批处理任务，计算并更新预聚合数据。
使用更高效的存储引擎和配置：选择适合业务场景的存储引擎（如InnoDB），并合理配置其参数（如缓冲池大小
innodb_buffer_pool_size
）。InnoDB缓冲池本身就是非常高效的数据和索引缓存，它比查询缓存更智能，因为它缓存的是数据页，而不是完整的查询结果。
这些现代优化策略，各有侧重，但都能在不同层面有效地提升SQL查询性能。它们共同构成了当前主流的数据库性能优化体系，远比依赖一个有缺陷的查询缓存来得可靠和高效。
以上就是SQL查询缓存如何利用_查询缓存配置与优化方法的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1058736.html
微信扫一扫 
支付宝扫一扫 
