好的，各位亲爱的程序猿、攻城狮、以及未来要改变世界的小码农们，欢迎来到今天的“MySQL 疑难杂症速诊室”。今天我们要聊一个老朋友，一个曾经风光无限，如今却略显尴尬的家伙——MySQL Query Cache！
别紧张，虽然它现在可能已经淡出你的视线，但了解它，就像了解一个老熟人的过往，可以让你在面对一些遗留系统或者排查性能问题时，更加得心应手。
今天的主题就是：使用 SET SESSION query_cache_type 临时禁用 Query Cache（历史兼容）。
废话不多说，让我们开始这场怀旧之旅吧！
一、Query Cache：曾经的辉煌与没落
想象一下，你是一位餐厅老板，每天都要处理大量的顾客点餐。如果每次顾客点同样的菜，你都要重新做一遍，那岂不是要累死？于是，你灵机一动，在厨房旁边设置了一个“预制菜区”，专门存放那些经常被点的菜。这样，当顾客再点这些菜时，你就可以直接从预制菜区拿出来，快速上菜，大大提高了效率。
MySQL Query Cache 就扮演着类似“预制菜区”的角色。它会缓存 SELECT 查询的结果，当下次收到同样的查询时，直接从缓存中返回结果，而不需要再次执行查询。这对于那些经常被执行的查询来说，简直是性能提升的利器！🚀
想当年，Query Cache 可是 MySQL 的明星功能，很多 DBA 都把它当作性能优化的法宝。开启 Query Cache，仿佛给数据库注入了一剂强心针，瞬间感觉性能飙升！
然而，好景不长。随着时间的推移，人们逐渐发现了 Query Cache 的一些问题：
- 锁的代价： Query Cache 的底层实现是基于全局锁的。这意味着，当一个查询正在读取或写入 Query Cache 时，其他查询都必须等待。在高并发场景下，全局锁会成为性能瓶颈。想象一下，你的“预制菜区”只有一个入口，每次只能允许一个人进入，那岂不是要排长队？
- 内存碎片： Query Cache 使用的是动态内存分配。频繁的写入和删除操作会导致内存碎片，降低缓存的利用率。这就好比你的“预制菜区”堆满了各种形状的容器，空间利用率很低。
- 缓存失效： 只要表中的数据发生任何变化，所有与该表相关的 Query Cache 都会失效。这意味着，即使只有一个小小的更新，也可能导致大量的缓存失效，浪费资源。这就好比你的“预制菜区”里的菜只要有一点点变质，就要全部倒掉，损失惨重。
- 命中率低： Query Cache 只能缓存完全相同的查询。即使只是大小写、空格或者注释的差异，都会导致缓存 Miss。这就好比你的“预制菜区”只接受完全一样的订单，稍微修改一下就不认账，太死板了。
正是由于这些问题，MySQL 5.7 开始不推荐使用 Query Cache，并在 MySQL 8.0 中彻底移除了它。一个时代的落幕，总是带着些许唏嘘。😢
二、SET SESSION query_cache_type：历史的遗留
虽然 Query Cache 已经被移除，但在一些老版本的 MySQL 中，它仍然存在。SET SESSION query_cache_type 就是一个用于控制 Query Cache 行为的会话级变量。
这个变量有三个可选值：
| 值 | 含义 |
|---|---|
0 或 OFF |
禁用 Query Cache。即使查询语句带有 SQL_CACHE 提示，也不会被缓存。相当于你的“预制菜区”被关闭了，所有菜都要重新做。 |
1 或 ON |
启用 Query Cache。默认情况下，所有符合条件的 SELECT 查询都会被缓存。但可以通过 SQL_NO_CACHE 提示来禁用缓存。相当于你的“预制菜区”正常运行，大部分菜都会被预制，但你可以手动指定某些菜不要预制。 |
2 或 DEMAND |
按需使用 Query Cache。只有查询语句带有 SQL_CACHE 提示，才会被缓存。相当于你的“预制菜区”只接受预定订单，只有顾客明确要求预制的菜才会进行预制。 |
需要注意的是，SET SESSION 命令只对当前会话有效。当会话结束后，设置就会失效。
三、为什么要临时禁用 Query Cache？
既然 Query Cache 已经不被推荐，甚至被移除，那为什么我们还要学习如何临时禁用它呢？原因很简单：
- 历史遗留系统： 很多老系统仍然在使用低版本的 MySQL，并且依赖于 Query Cache。在这些系统中，临时禁用 Query Cache 可以帮助我们诊断性能问题。例如，如果怀疑 Query Cache 导致了性能瓶颈，我们可以先临时禁用它，看看性能是否有所改善。
- 测试环境： 在测试环境中，我们可能需要模拟各种场景。临时禁用 Query Cache 可以帮助我们测试在没有缓存的情况下，应用程序的性能表现。
- 特定场景： 在某些特定的场景下，Query Cache 可能会适得其反。例如，对于那些数据更新非常频繁的表，Query Cache 的缓存失效会导致性能下降。在这种情况下，我们可以临时禁用 Query Cache，避免不必要的开销。
总之，掌握如何临时禁用 Query Cache，可以让我们在面对各种复杂情况时，更加灵活应对。
四、如何使用 SET SESSION query_cache_type 临时禁用 Query Cache？
使用 SET SESSION query_cache_type 临时禁用 Query Cache 非常简单。只需要在 MySQL 客户端中执行以下命令即可：
SET SESSION query_cache_type = 0;或者
SET SESSION query_cache_type = OFF;执行完这条命令后，当前会话中的所有 SELECT 查询都不会被缓存。
示例：
假设我们有一个名为 users 的表，其中包含 id 和 name 两个字段。
首先，我们开启 Query Cache，并执行一个 SELECT 查询：
SET SESSION query_cache_type = 1;
SELECT SQL_CACHE * FROM users WHERE id = 1;这条查询的结果会被缓存到 Query Cache 中。
然后，我们临时禁用 Query Cache，并再次执行同样的 SELECT 查询：
SET SESSION query_cache_type = 0;
SELECT SQL_CACHE * FROM users WHERE id = 1;虽然这条查询语句带有 SQL_CACHE 提示，但由于我们已经禁用了 Query Cache，所以它不会被缓存。
五、注意事项
SET SESSION query_cache_type只对当前会话有效。如果需要永久禁用 Query Cache，需要在 MySQL 配置文件中进行设置。- 在 MySQL 8.0 及以上版本中，Query Cache 已经被移除，
SET SESSION query_cache_type命令无效。 - 如果怀疑 Query Cache 导致了性能问题，建议先禁用 Query Cache，看看性能是否有所改善。如果性能确实有所改善，可以考虑优化查询语句，或者使用其他缓存机制，例如 Redis 或 Memcached。
- 请记得，Query Cache 并不能解决所有性能问题。在优化数据库性能时，需要综合考虑各种因素，例如索引、查询语句、硬件配置等。
六、Query Cache 的替代方案
既然 Query Cache 已经过时，那有没有什么替代方案呢？当然有！
- 索引： 索引是提高查询性能的最有效手段之一。通过合理地创建索引，可以大大减少数据库的扫描范围，提高查询速度。
- 查询优化： 优化查询语句，避免全表扫描，可以显著提高查询性能。可以使用
EXPLAIN命令来分析查询语句的执行计划，找出需要优化的地方。 - 缓存机制： 可以使用 Redis 或 Memcached 等缓存机制，将常用的数据缓存到内存中，减少数据库的访问压力。
- 预编译查询： 使用预编译查询，可以避免重复解析查询语句，提高查询效率。
七、总结
Query Cache 曾经是 MySQL 的一个重要特性，但由于其自身的缺陷，最终被移除。虽然 Query Cache 已经过时，但了解它，可以帮助我们更好地理解 MySQL 的发展历程，并在面对一些遗留系统时，更加得心应手。
SET SESSION query_cache_type 命令可以临时禁用 Query Cache，用于诊断性能问题或模拟特定场景。
在优化数据库性能时，需要综合考虑各种因素，选择合适的解决方案。不要盲目迷信 Query Cache，也不要轻易否定其他优化手段。
希望今天的分享对你有所帮助。记住，代码的世界是充满乐趣的，保持好奇心，不断学习，你就能成为一名优秀的程序员！💪
最后，送给大家一句名言：
"Talk is cheap. Show me the code." – Linus Torvalds
感谢大家的收听，我们下期再见！ 👋