如何清理MySQL 的查询缓存
Posted
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了如何清理MySQL 的查询缓存相关的知识，希望对你有一定的参考价值。
mysql的FLUSH可以清理mysql数据库缓存数据MySQL的FLUSH句法(清除或者重新加载内部缓存） FLUSH flush_option [,flush_option]，如果你想要清除一些MySQL使用内部缓存，你应该使用FLUSH命令。为了执行FLUSH，你必须有reload权限。
flush_option 可以是下列任何东西：
HOSTS 这个用的最多，经常碰见。主要是用来清空主机缓存表。如果你的某些主机改变IP数字，或如果你得到错误消息Host ... isblocked，你应该清空主机表。当在连接MySQL服务器时，对一台给定的主机有多于 max_connect_errors个错误连续不断地发生，MySQL为了安全的需要将会阻止该主机进一步的连接请求。清空主机表允许主机再尝试连接。
LOGS 关闭当前的二进制日志文件并创建一个新文件，新的二进制日志文件的名字在当前的二进制文件的编号上加1。
PRIVILEGES 这个也是经常使用的，每当重新赋权后，为了以防万一，让新权限立即生效，一般都执行一把，目地是从数据库授权表中重新装载权限到缓存中。
TABLES 关闭所有打开的表，同时该操作将会清空查询缓存中的内容。
FLUSH TABLES WITH READ LOCK 关闭所有打开的表，同时对于所有数据库中的表都加一个读锁，直到显示地执行unlock tables，该操作常常用于数据备份的时候。解锁的语句就是unlock tables。
FLUSH TABLES WITH READ LOCK对于数据库是全局的表锁定，如果只想锁定几个表，可以用LOCK TABLES tbl_name [AS alias] READ [LOCAL] | [LOW_PRIORITY] WRITE 。这个命令同样需要unlock tables来解锁。
read-lock: 允许其他并发的读请求，但阻塞写请求，即可以同时读，但不允许任何写。也叫共享锁。write-lock: 不允许其他并发的读和写请求，是排他的(exclusive)。也叫独占锁
STATUS 重置大多数状态变量到0。
MASTER 删除所有的二进制日志索引文件中的二进制日志文件，重置二进制日志文件的索引文件为空，创建一个新的二进制日志文件,不过这个已经不推荐使用，改成reset master 了。可以想象，以前自己是多土啊，本来一条简单的命令就可以搞定的，却要好几条命令来，以前的做法是先查出来当前的二进制日志文件名，再用purge 操作。
QUERY CACHE 重整查询缓存，消除其中的碎片，提高性能，但是并不影响查询缓存中现有的数据，这点和Flush table 和Reset Query Cache（将会清空查询缓存的内容）不一样的。
SLAVE 类似于重置复制吧，让从数据库忘记主数据库的复制位置，同时也会删除已经下载下来的relay log,与Master一样，已经不推荐使用，改成Reset Slave了。这个也很有用的。
一般来讲，Flush操作都会记录在二进制日志文件中，但是FLUSH LOGS、FLUSH MASTER、FLUSH SLAVE、FLUSH TABLES WITH READ LOCK不会记录，因此上述操作如果记录在二进制日志文件中话，会对从数据库造成影响。 参考技术A
MySQL 8.0.16 已经发布，它像往常一样增强了组复制 Group Replication 功能。
这篇文章介绍了 MySQL 8.0.16 为 Group Replication 带来的新功能：
Message fragmentation（信息碎片化）。
背景
Group Replication 目前使用 XCom（一种组通信引擎），特点：原子性，组员状态检测等。每个成员的组复制插件先将信息转发到本地 XCom，再由 XCom 最终以相同的顺序将信息传递给每个组成员的 Group Replication 插件。
XCom 由单线程实现。当一些成员广播信息过大时，XCom 线程必须花费更多的时间来处理那个大信息。如果成员的 XCom 线程忙于处理大信息的时间过长，它可能会去查看其他成员的 XCom 实例。例如，忙碌的成员失效。如果是这样，该组可以从该组中驱逐忙碌的成员。
MySQL 8.0.13 新增 group_replication_member_expel_timeout 系统变量，您可以通过它来调整将成员从组中驱逐的时间。例如，怀疑成员失败，但成员实际上忙于处理大信息，给成员足够的时间来完成处理。在这种情况下，是否为成员增加驱逐超时的设置是一种权衡。有可能等了很久，该成员实际真的失效了。
Message fragmentation（信息碎片化）
MySQL 8.0.16 的 Group Replication 插件新增用来处理大信息的功能：信息碎片化。
简而言之，您可以为成员的广播信息指定最大值。超过最大值的信息将分段为较小的块传播。
您可以使用 group_replication_communication_max_message_size 系统变量指定允许的信息最大值（默认值为10 MiB）。
示例
让我们用一个例子来解释新功能。图1显示了当绿色成员向组广播信息时，新功能是如何处理的。
图1 对传出信息进行分段
1. 如果信息大小超过用户允许的最大值（group_replication_communication_max_message_size），则该成员会将信息分段为不超过最大值的块。
2. 该成员将每个块广播到该组，即将每个块单独转发到XCom。
XCom 最终将这些块提供给组成员。下面三张图展示出了中间绿色成员发送大信息时工作的新特征。
图2a 重新组合传入的信息：第一个片段
3. 成员得出结论，传入的信息实际上是一个更大信息的片段。
4. 成员缓冲传入的片段，因为他们认为片段是仍然不完整的信息的一部分。（片段包含必要的元数据以达到这个结论。）
图2b 重新组合传入的信息：第二个片段
5. 见上面的第3步。
6. 见上面的第4步。
图2c 重新组合传入的信息：最后一个片段
7. 成员得出结论，传入的信息实际上是一个更大信息的片段。
8. 成员得出结论，传入的片段是最后一个缺失的块，重新组合原始信息，然后对其进行处理，传输完毕。
结论
MySQL 8.0.16 已经发布后，组复制现在可以确保组内交换的信息大小不超过用户定义的阈值。这可以防止组内误判而驱逐成员。
MySQL进阶实战11，查询缓存
目录
一、查询缓存是什么？
MySQL查询缓存保存查询返回的完整结果，当查询命中该缓存，MySQL会立刻返回结果，跳过解析、优化和执行过程。
查询缓存系统会跟踪查询中涉及的每个表，如果这些表发生变化，那么和这个表相关的所有的缓存数据都将失效，这种机制效率看起来比较低，因为数据表变化时可能对查询结果并没有影响，但是这种简单实现代价很小，而这点对于一个非常繁忙的系统来说非常重要。
二、MySQL如何判断缓存命中
判断是否命中时，MySQL不会解析，而是直接使用SQL语句和客户端发送过来的其它原始信息。任何字符上的不同，例如空格、注释，丢回导致缓存的不命中。通常使用统一的编码规则是一个好的习惯，会让你的系统运行的更快。
当查询语句中有一些不确定的数据时，不会被缓存，比如函数now()。实际上，如果缓存中包含任何用户自定义函数、存储函数、用户变量、临时表、MySQL系统表、或者任何包含列级别权限的表，都不会被缓存。
三、使用查询缓存需谨慎
打开查询缓存对读和写操作都会带来额外的消耗：
- 读查询在执行之前要先检查是否命中缓存；
- 如果读查询可以被缓存，那么当完成执行后，MySQL如果发现缓存中没有这个查询，会将其结果存入查询缓存，这会带来额外的系统消耗；
- 对写操作也有影响，因为当向某个表写入数据的时候，MySQL必须将对应表的所有缓存设置失效。如果查询缓存非常大或者碎片很多，这个操作就可能会带来很大的系统消耗；
虽然如此，查询缓存仍然会给系统带来性能的提升。但是，上述的额外消耗也可能不断增加，再加上对查询缓存操作是一个加锁排它操作，这个消耗也不小。
对InnoDB用户来说，事务的一些特性会限制查询缓存的使用。当一个语句在事务中修改了某个表，在事务提交前，MySQL都会将这个表对应的查询缓存设置失效，因此，长时间运行的事务，会大大降低查询缓存的命中率。
四、如何分析和配置查询缓存
五、InnoDB和查询缓存
因为InnoDB有自己的MVCC机制，所以相比其它存储引擎，InnoDB和查询缓存的交互要更加复杂。
MVCC是多版本并发控制，是为了在读取数据时不加锁来提高读取效率和并发性的一种手段。MVCC解决的是读写时的线程安全问题，线程不用去争抢读写锁。
MVCC所提到的读是快照读，也就是普通的select语句，快照读在读写时不用加锁，不过可能会读到历史数据。
另一种读的方式是当前读，是一种悲观锁的操作，它会对当前读取的数据进行加锁，所以读到的数据都是最新的，主要包括以下操作：
- select lock in share mode，共享锁
- select for update，排它锁
- insert，排它锁
- update，排它锁
- delete，排它锁
InnoDB会控制在一个事务中是否可以使用查询缓存，InnoDB会同时控制对查询缓存的读写操作。事务是否可以访问查询缓存取决于当前事务的ID，以及对应的数据表上是否有锁。每一个InnoDB表的内存数据字典都保存了一个事务ID号，如果当前事务ID小于该事务ID，则无法访问查询缓存。
如果表上有任何的锁，那么对这个表的任何查询语句都是无法被缓存的。例如，某个事务执行了select for update语句，那么在这个锁释放之前，任何其它的事务都无法从查询缓存中读取与这个表相关的缓存结果。
当事务提交时，InnoDB持有锁，并使用当前的一个系统事务ID更新当前表的计数器。InnoDB将每个表的计数器设置成某个事务ID，而这个事务ID就代表了当前存在的且修改了该表的最大的事务ID。
MySQL进阶实战系列文章
MySQL进阶实战9，InnoDB和MyISAM的数据分布对比
哪吒精品系列文章
以上是关于如何清理MySQL 的查询缓存的主要内容，如果未能解决你的问题，请参考以下文章