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

调整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：完全禁用查询缓存。
• query_cache_type0 或 query_cache_type1：启用查询缓存。所有不以query_cache_type2开头的查询都会被缓存，前提是它们满足缓存条件。
• query_cache_type3 或 query_cache_type4：按需启用。只有以query_cache_type5开头的查询才会被缓存。

示例配置：

[mysqld] query_cache_type = ON

3. 动态调整（仅限query_cache_type和query_cache_size在非0时）： 你可以在MySQL运行时使用query_cache_type8命令来修改这两个参数，但这些更改在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开销都大大降低了。

存了个图

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

17

查看详情

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

• 失效机制过于粗糙： 只要缓存中的任何一个表发生数据修改（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缓冲池（my.cnf1），它缓存了数据页和索引页，这比缓存整个查询结果集更底层、更高效。
• 硬件升级： 增加内存、使用SSD等高性能存储，提升CPU性能，这些都能直接提升数据库的处理能力。

总而言之，MySQL 8.0移除了查询缓存，并非是让你失去一个优化工具，而是促使你转向更现代、更有效的性能优化实践。

除了查询缓存，还有哪些常见的MySQL性能优化手段？

抛开查询缓存这个“历史遗留问题”，MySQL的性能优化是一个系统工程，涉及多个层面。以下是一些在我看来非常重要且常用的优化手段：

1. 索引优化： 这是最基础也是最重要的优化手段。一个好的索引设计能让查询速度提升几个数量级。

• 选择合适的索引类型： B-tree索引适用于大多数场景，哈希索引适用于等值查询，全文索引适用于文本搜索。
• 为WHERE、JOIN、ORDER BY、GROUP BY子句中的列创建索引。
• 利用复合索引： 注意索引列的顺序，遵循“最左前缀原则”。
• 避免冗余索引： 过多的索引会增加写入开销和存储空间。
• 定期分析和优化： 使用my.cnf2命令分析SQL查询的执行计划，找出没有使用索引或索引使用不当的地方。

2. SQL语句优化： 直接优化你的查询语句，减少不必要的计算和数据传输。

• *避免`SELECT `：** 只选择你需要的列，减少网络传输和内存消耗。
• 优化my.cnf3操作： 确保my.cnf3条件上有索引，选择合适的my.cnf3类型（INNER JOIN, LEFT JOIN等）。
• 避免子查询： 很多子查询可以重写为my.cnf3或my.cnf7，通常性能更好。
• 减少my.cnf8的使用： 这种模式的模糊匹配无法利用索引，考虑使用全文索引或搜索引擎。
• 分页优化： 对于大偏移量的分页查询，避免my.cnf9直接查询，可以先通过索引定位到起始ID，再进行查询。

3. 服务器硬件和操作系统优化： 数据库性能离不开强大的硬件支持。

• 足够的内存（RAM）： 确保my.cnf1能容纳大部分热点数据和索引。
• 高性能存储（SSD/NVMe）： 提升I/O吞吐量，减少磁盘等待时间。
• 多核CPU： 处理并发查询和后台任务。
• 操作系统参数调优： 例如文件句柄数限制、网络缓冲区大小等。

4. MySQL配置参数调优： 除了查询缓存，MySQL还有许多关键参数需要根据实际负载进行调整。

• my.cnf1： InnoDB最重要的参数，直接影响读写性能。
• my.ini2： 最大连接数，防止连接过多导致服务器崩溃。
• my.ini3和my.ini4： 内部临时表的大小，影响排序和分组操作的性能。
• my.ini5、my.ini6： 影响排序和连接操作的内存使用。
• my.ini7和my.ini8： 影响写入性能和数据一致性。

5. 慢查询日志分析： 开启慢查询日志（my.ini9），记录执行时间超过query_cache_size0的SQL语句。定期分析这些日志，找出性能瓶颈。

• 使用query_cache_size1或query_cache_size2等工具分析日志，找出执行次数最多、耗时最长的慢查询。

6. 数据库架构优化： 对于高并发、大数据量的场景，可能需要调整数据库架构。

• 读写分离： 将读操作分发到多个从库，减轻主库压力。
• 分库分表（Sharding）： 将数据分散到多个数据库或表中，突破单机性能瓶颈。
• 选择合适的存储引擎： 大多数OLTP场景使用InnoDB，但对于特定的日志或归档数据，可能考虑其他引擎。

7. 连接池： 在应用程序中使用数据库连接池，可以复用数据库连接，减少连接建立和关闭的开销，提高应用响应速度。

这些优化手段并非相互独立，往往需要综合运用，并根据实际的业务场景和性能瓶颈进行针对性的调整和测试。性能优化是一个持续的过程，需要不断监控、分析和迭代。