MySQL 8.0 移除 Query Cache 查询缓存
文章目录[隐藏]
- 什么是 Query Cache ？
- Query Cache 缺点
- Query Cache 被弃用
今天，只花了19.9买了一台阿里云 MySQL 云数据库，虽然配置只有 1 核 1G（云数据库活动传送门），但却是实实在在的 MySQL 8.0。要知道单独安装 MySQL 8.0 可是会提示“最低内存要求 3700MB，最少CPU数：2个”，而现在，我可以享受阿里云 MySQL 云数据库的服务同时，又能降低网站服务器资源的占用，实在太棒了。通过 MySQL 参数设置发现，MySQL 8.0 去除了 Query Cache 查询缓存。
什么是 Query Cache ？
对于缓存，一般人想到的是 Redis、Memcache 这些内存型的缓存。但是实际上 MySQL 5.5-5.7 版本也提供了 Query Cache 查询缓存，可以把我们查询过的语句缓存下来，下一次查询的时候有可能就直接从缓存返回（缓存命中）。这里引用下文档介绍：
stores the text of a SELECT statement together with the corresponding result that was sent to the client. If an identical statement is received later, the server retrieves the results from the query cache rather than parsing and executing the statement again
Query Cache 缺点
当然使用 Query Cache 缓存也不是没有坏处，多了个管理缓存的任务，需要写入缓存，然后如果判断里面的缓存已经过期，又要从里面删除缓存。
随着技术的进步，经过时间的考验，MySQL 工程团队发现启用 Query Cache 查询缓存的好处并不多。
首先，查询缓存的效果取决于缓存的命中率，只有命中缓存的查询效果才能有改善，因此无法预测其性能。
其次，查询缓存的另一个大问题是它受到单个互斥锁的保护。在具有多个内核的服务器上，大量查询会导致大量的互斥锁争用。
通过基准测试发现，大多数工作负载最好（5.6的默认设置）：query_cache_type = 0
如果你认为会从 MySQL 数据库 Query Cache 查询缓存中获得好处，请按照实际情况进行测试。
- 数据写的越多，好处越少；
- 缓冲池中容纳的数据越多，好处越少；
- 查询越复杂，扫描范围越大，则越受益。
Query Cache 被弃用
MySQL 8.0 不在支持 Query Cache 查询缓存，因此 Query Cache 相关的参数也被移除：
- query_cache_type
- query_cache_size
尽管 MySQL Query Cache 查询缓存旨在提高性能，但它存在严重的可扩展性问题，并且很容易成为严重的瓶颈。通过研究，缓存越靠近客户端，获得的好处越大。
所以，你如果是 WordPress 站长，并且已经开始使用 MySQL 8.0，那么应该考虑的是根据网站实际情况进行优化加速。可以着重于内存缓存、浏览器等更加靠近用户端的缓存。
