MySQL高阶讲座之：`MySQL`的`Query Cache`：其在`MySQL` 8.0中被移除的深层原因。 - 智猿学院-前后端，数据库，人工智能，云计算等领域前沿技术讲座

各位朋友，大家好！我是今天的主讲人，咱们今天聊聊MySQL里曾经风光无限，但最终黯然退场的 Query Cache。这玩意儿啊，就像你辛辛苦苦做的缓存，结果发现不仅没加速，还拖慢了速度，最后只能忍痛割爱。

一、Query Cache：曾经的“加速神器”

话说在MySQL 5.7及之前的版本里，Query Cache 绝对是明星功能。它的作用简单粗暴：把 SELECT 查询的结果缓存起来。下次再执行同样的查询，直接从缓存里拿结果，省去了分析SQL、访问数据、计算结果的步骤，速度提升那是杠杠的。

想象一下，你是个饭店老板。每天都有很多顾客点相同的菜，比如“宫保鸡丁”。如果每次都重新炒一遍，那得多费劲？Query Cache 就相当于你提前炒好一大锅“宫保鸡丁”，有人点就直接盛一份，大大提高了出菜效率。

举个例子，假设我们有这么一张表：

CREATE TABLE articles (
  id INT PRIMARY KEY AUTO_INCREMENT,
  title VARCHAR(255) NOT NULL,
  content TEXT,
  created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

INSERT INTO articles (title, content) VALUES
('MySQL Query Cache Explained', 'This is the content of the article.'),
('Benefits of Using Indexes', 'Indexes can significantly improve query performance.'),
('Understanding Transactions', 'Transactions ensure data consistency.');

现在执行一个简单的查询：

SELECT title FROM articles WHERE id = 1;

第一次执行，MySQL 会老老实实地从表中读取数据。但如果启用了 Query Cache，这个查询的结果就会被缓存起来。下次再执行同样的查询，MySQL 直接从缓存里返回结果，速度嗖嗖的。

二、Query Cache 的工作原理：缓存的“小心思”

Query Cache 的工作原理可以用下图简单表示：

[客户端] --> [MySQL服务器] --> [Query Cache] --> [查询分析器] --> [优化器] --> [执行器] --> [存储引擎]
                                  ^     |
                                  |     | 命中缓存，直接返回结果
                                  |_____| 未命中缓存，执行查询

简单来说，就是这么几个步骤：

接收查询： 客户端发送查询语句到 MySQL 服务器。
检查缓存： MySQL 服务器先去 Query Cache 里看看有没有对应的缓存。
命中缓存： 如果找到了缓存，直接把结果返回给客户端，查询结束。
未命中缓存： 如果没找到缓存，就按照正常的流程，经过查询分析器、优化器、执行器，访问存储引擎，获取数据。
缓存结果： 把查询结果和查询语句一起存到 Query Cache 里，以便下次使用。

Query Cache 在缓存的时候，会考虑以下几个因素：

SQL 语句： 必须完全一样，包括空格、大小写等等。
数据库： 必须是同一个数据库。
用户权限： 必须是同一个用户，并且拥有相同的权限。
变量： 必须是相同的会话变量。

只有以上条件都满足，才能命中 Query Cache。

三、Query Cache 的“阿喀琉斯之踵”：致命的缺陷

Query Cache 听起来很美好，但实际上却存在着很多问题，最终导致它被 MySQL 8.0 无情地抛弃。

缓存失效： 这是 Query Cache 最让人头疼的问题。只要表中的数据发生任何变化（INSERT、UPDATE、DELETE），Query Cache 中所有与该表相关的缓存都会失效。这就像你刚炒好一锅“宫保鸡丁”，结果有人说要加点辣椒，你只能把整锅都倒掉，重新炒。

频繁的缓存失效会导致 Query Cache 的命中率非常低，甚至低于 10%。这意味着大部分查询都无法利用缓存，Query Cache 几乎成了摆设。

锁的争用： Query Cache 使用一个全局锁来控制并发访问。这意味着，当一个线程在访问 Query Cache 时，其他线程必须等待。在高并发的场景下，锁的争用会非常激烈，导致性能下降。这就像只有一个厨师在炒“宫保鸡丁”，所有顾客都得排队等着吃。

可以用以下代码模拟高并发场景下的锁争用：

import threading
import mysql.connector

# MySQL 连接信息
config = {
    'user': 'your_user',
    'password': 'your_password',
    'host': 'localhost',
    'database': 'your_database'
}

# 查询语句
query = "SELECT title FROM articles WHERE id = 1"

# 线程函数
def execute_query():
    try:
        cnx = mysql.connector.connect(**config)
        cursor = cnx.cursor()
        cursor.execute(query)
        result = cursor.fetchall()
        cursor.close()
        cnx.close()
        print(f"Thread {threading.current_thread().name}: Query executed successfully.")
    except mysql.connector.Error as err:
        print(f"Thread {threading.current_thread().name}: Error executing query: {err}")

# 创建多个线程
threads = []
for i in range(100):
    thread = threading.Thread(target=execute_query, name=f"Thread-{i}")
    threads.append(thread)
    thread.start()

# 等待所有线程结束
for thread in threads:
    thread.join()

print("All threads finished.")

这段代码会创建 100 个线程，每个线程都执行相同的查询。在高并发的情况下，Query Cache 的全局锁会导致线程之间相互等待，降低了整体性能。

内存碎片： Query Cache 使用动态内存分配，频繁的缓存创建和失效会导致内存碎片。内存碎片会降低内存的利用率，甚至导致 OOM（Out of Memory）错误。这就像你的厨房里到处都是零碎的食材，浪费空间，还容易滋生细菌。
维护成本高： Query Cache 的代码非常复杂，维护成本很高。随着 MySQL 的不断发展，Query Cache 逐渐变得难以维护，最终被放弃。

四、MySQL 8.0 的“断舍离”：告别 Query Cache

MySQL 8.0 毅然决然地移除了 Query Cache。这一举动虽然让很多人感到惋惜，但也是大势所趋。Query Cache 的缺陷已经严重影响了 MySQL 的性能和稳定性，继续保留它只会适得其反。

MySQL 8.0 并没有完全放弃缓存，而是采用了更加高效和灵活的方案，例如：

优化器增强： MySQL 8.0 的优化器更加智能，能够生成更高效的执行计划，减少了对缓存的依赖。
InnoDB Buffer Pool： InnoDB Buffer Pool 仍然是重要的缓存机制，用于缓存数据和索引。
客户端缓存： 鼓励在客户端使用缓存，例如使用 Redis 或 Memcached。

五、Query Cache 的“替代品”：新的选择

既然 Query Cache 已经不在了，那我们该如何优化查询性能呢？以下是一些常用的方法：

索引： 这是最基本也是最重要的优化手段。合理的索引可以大大减少查询需要扫描的数据量。

例如，在 articles 表中，我们可以为 title 字段创建一个索引：
```
CREATE INDEX idx_title ON articles (title);
```
这样，当执行 SELECT * FROM articles WHERE title = 'MySQL Query Cache Explained' 时，MySQL 就可以直接通过索引找到对应的记录，而不需要扫描整个表。
查询优化： 编写高效的 SQL 语句，避免全表扫描、使用 SELECT *、使用 OR 等等。

例如，尽量避免使用 SELECT *，只选择需要的字段：
```
-- 不推荐
SELECT * FROM articles WHERE id = 1;

-- 推荐
SELECT title, content FROM articles WHERE id = 1;
```
连接池： 使用连接池可以减少数据库连接的创建和销毁开销。

可以使用 HikariCP、DBCP 等连接池。

缓存： 在客户端或中间层使用缓存，例如 Redis、Memcached。

例如，可以使用 Redis 缓存查询结果：

import redis

# Redis 连接信息
redis_host = 'localhost'
redis_port = 6379
redis_db = 0

# 连接 Redis
r = redis.Redis(host=redis_host, port=redis_port, db=redis_db)

# 查询语句
query = "SELECT title FROM articles WHERE id = 1"

# 从 Redis 获取缓存
cached_result = r.get(query)

if cached_result:
    # 命中缓存
    result = cached_result.decode('utf-8')
    print("Result from cache:", result)
else:
    # 未命中缓存
    try:
        cnx = mysql.connector.connect(**config)
        cursor = cnx.cursor()
        cursor.execute(query)
        result = cursor.fetchone()[0]
        cursor.close()
        cnx.close()
        print("Result from database:", result)

        # 缓存结果到 Redis
        r.set(query, result)
        r.expire(query, 60) # 设置过期时间为 60 秒
    except mysql.connector.Error as err:
        print(f"Error executing query: {err}")

这段代码首先尝试从 Redis 获取缓存，如果命中缓存，直接返回结果。如果未命中缓存，则从数据库查询，并将结果缓存到 Redis 中，并设置过期时间。

读写分离： 将读操作和写操作分到不同的数据库服务器上，减轻主库的压力。
分库分表： 将数据分散到多个数据库服务器上，提高系统的并发处理能力。

六、总结：拥抱变化，迎接未来

Query Cache 的移除是 MySQL 发展过程中的一个重要里程碑。它告诉我们，没有一成不变的技术，只有不断进步和适应才能在激烈的竞争中生存下来。

虽然 Query Cache 已经成为了历史，但它留给我们的教训却是宝贵的。我们需要时刻关注技术的发展趋势，不断学习新的知识，才能更好地应对未来的挑战。

最后，用一句玩笑话来结束今天的讲座：

“Query Cache 走了，留下了优化器和 Redis，深藏功与名！”

感谢大家的聆听！希望今天的讲座对大家有所帮助。如果有什么问题，欢迎随时提问。

发表回复 取消回复

发表回复取消回复