一文读懂一条 SQL 查询语句是如何执行的( 三 )

在 MyQL 的默认设置中，如果一个连接处在 Sleep 状态 8 小时（就是超过 8 小时没有使用），服务器将断开这条连接，后续在该连接上进行的所有操作都将失败。这个时间是由参数 wait_timeout 控制的：

本文插图
OK ，连接建立完成后，我们就可以输入 select 语句进行查询了。执行逻辑就来到了第二步：查询缓存。
官方文档是这样解释 Query Cache 的：
The 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. The query cache is shared among sessions, so a result set generated by one client can be sent in response to the same query issued by another client.
就是说查询缓存存储了 SELECT 语句的文本以及响应给客户端的相应结果。这样，如果服务器稍后接收到相同的 SELECT 语句，服务器会先从查询缓存中检索结果，而不是再次解析和执行该语句。查询缓存在 session 之间共享，因此可以发送一个客户端生成的结果集以响应另一个客户端发出的相同查询。
如果当前的查询恰好命中了查询缓存，那么在返回查询结果之前 MySQL 会检查一次用户权限。这仍然是无须解析查询SQL语句的，因为在查询缓存中已经存放了当前查询需要访问的表信息。
那么既然涉及到缓存，就必然绕不开缓存一致性问题了。值得庆幸的是，不需要我们进行额外操作，查询缓存并不会返回陈旧数据！
The query cache does not return stale data. When tables are modified, any relevant entries in the query cache are flushed.
当表被修改时，查询缓存中的任何相关条目都会被 flushed ，注意，这里的 flushed 翻译为清空而不是刷新。
看起来好像还不错？不用我们手动操作，失效缓存就能够被自动清空。
然而，很不幸的是，正是由于这个特性，从 MySQL 5.7.20 开始，官方不再推荐使用查询缓存，并在 MySQL 8.0 中直接删除了查询缓存！
The query cache is deprecated as of MySQL 5.7.20, and is removed in MySQL 8.0.
其实不难理解，举个例子，对于一个流量很大的论坛项目来说，查询帖子表的需求每时每刻都存在，帖子也几乎每时每刻都在增加，那只要这个表一更新，这个表上所有的查询缓存都会被清空，这对于 MySQL 数据库的压力之大，可想而知了吧。费个劲把查询结果存起来，还没来得及使用呢，就被一个更新全清空了。
对于 MySQL 8.0 之前的版本来说，你可以将参数 query_cache_type 设置成 DEMAND ，这样所有的 SQL 语句都不会再使用查询缓存。而对于你确定要使用查询缓存的语句，可以用 SQL_CACHE 显式指定，像下面这个语句一样：