MySQL的FLUSH可以清理mysql数据库缓存数据
10年积累的成都网站设计、成都网站建设经验，可以快速应对客户对网站的新想法和需求。提供各种问题对应的解决方案。让选择我们的客户得到更好、更有力的网络服务。我虽然不认识你，你也不认识我。但先网站设计后付款的网站建设流程，更有濮阳免费网站建设让你可以放心的选择与我们合作。
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不会记录，因此上述操作如果记录在二进制日志文件中话，会对从数据库造成影响。
如果数据库是安装在你机器上的 那么你可以暂时把MYSQL关闭 然后进入安装目录 找到data文件夹 这里面就是放置数据库文件的。。你会看到data里面每一个文件夹都对应你一个数据库名称 把他们删除就好了 就彻底没了 不过可别把mysql这个文件夹删了 还有别的文件 比如.err别乱删哦。
如果这个你不会 或者说文件在使用删除不了 那么你就用mysql的可视化工具 比如mysql-front 5.1 进去删除 效果都是一样。
mysql 开启查询缓存可以有两种方法来开启一种是使用set命令来进行开启，另一种是直接修改my.ini文件来直接设置都是非常的简单的哦。
开启缓存，设置缓存大小，具体实施如下：
windows下是my.ini，linux下是my.cnf;
在配置文件的最后追加上：
需要重启mysql生效；
b) 开启缓存,两种方式：
a)使用mysql命令：
如果报错：
Query cache is disabled; restart the server with query_cache_type=1 to enable it，还是老老实实的该配置文件，然后重启吧，原因如下：
查看是否设置成功
show variables like "%query_cache%" 查看是否设置成功：
当然如果你的数据表有更新怎么办，没关系mysql默认会和这个表有关系的缓存删掉，下次查询的时候会直接读表然后再缓存
下面是一个简单的例子：
以上的相关内容就是对mysql缓存查询和设置的介绍，望你能有所收获。
一般，我们会把 query_cache_type 设置为 ON,默认情况下应该是ON
query_cache_type有3个值 0代表关闭查询缓存OFF，1代表开启ON，2（DEMAND）代表当sql语句中有SQL_CACHE关键词时才缓存，如：
这样 当我们执行 select id,name from tableName; 这样就会用到查询缓存。
①在 query_cache_type 打开的情况下，如果你不想使用缓存，需要指明
select sql_no_cache id,name from tableName;
②当sql中用到mysql函数，也不会缓存
当然也可以禁用查询缓存： mysql set session query_cache_type=off;
上面的显示，表示设置查询缓存是可用的。
表示查询缓存大小，也就是分配内存大小给查询缓存，如果你分配大小为0，
那么 第一步 和 第二步 起不到作用，还是没有任何效果。
上面是 mysql6.0设置默认的，之前的版本好像默认是0的，那么就要自己设置下。
设置
这里是设置1M左右，900多K。
再次查看下:
显示我们设置新的大小，表示设置成功。
例如： 如果查询结果很大， 也缓存？？？？这个明显是不可能的。
MySql 可以设置一个最大的缓存值，当你查询缓存数结果数据超过这个值就不会
进行缓存。缺省为1M，也就是超过了1M查询结果就不会缓存。
这个是默认的数值，如果需要修改，就像设置缓存大小一样设置，使用set
重新指定大小。
好了，通过4个步骤就可以 打开了查询缓存，具体值的大小和查询的方式 这个因不同
的情况来指定了。
mysql查询缓存相关变量
MySQL 提供了一系列的 Global Status 来记录 Query Cache 的当前状态，具体如下：
Qcache_free_blocks：目前还处于空闲状态的 Query Cache 中内存 Block 数目
Qcache_free_memory：目前还处于空闲状态的 Query Cache 内存总量
Qcache_hits：Query Cache 命中次数
Qcache_inserts：向 Query Cache 中插入新的 Query Cache 的次数，也就是没有命中的次数
Qcache_lowmem_prunes：当 Query Cache 内存容量不够，需要从中删除老的 Query Cache 以给新的 Cache 对象使用的次数
Qcache_not_cached：没有被 Cache 的 SQL 数，包括无法被 Cache 的 SQL 以及由于 query_cache_type 设置的不会被 Cache 的 SQL
Qcache_queries_in_cache：目前在 Query Cache 中的 SQL 数量
Qcache_total_blocks：Query Cache 中总的 Block 数量
检查是否从查询缓存中受益的最简单的办法就是检查缓存命中率
当服务器收到SELECT 语句的时候，Qcache_hits 和Com_select 这两个变量会根据查询缓存
的情况进行递增
查询缓存命中率的计算公式是：Qcache_hits/(Qcache_hits + Com_select)。
query_cache_min_res_unit的配置是一柄”双刃剑”，默认是4KB，设置值大对大数据查询有好处，但如果你的查询都是小数据 查询，就容易造成内存碎片和浪费。
查询缓存碎片率 = Qcache_free_blocks / Qcache_total_blocks * 100%
如果查询缓存碎片率超过20%，可以用FLUSH QUERY CACHE整理缓存碎片，或者试试减小query_cache_min_res_unit，如果你的查询都是小数据量的话。
查询缓存利用率 = (query_cache_size - Qcache_free_memory) / query_cache_size * 100%
查询缓存利用率在25%以下的话说明query_cache_size设置的过大，可适当减小;查询缓存利用率在80%以上而且 Qcache_lowmem_prunes 50的话说明query_cache_size可能有点小，要不就是碎片太多。
查询缓存命中率 = (Qcache_hits - Qcache_inserts) / Qcache_hits * 100%
示例服务器 查询缓存碎片率 = 20.46%，查询缓存利用率 = 62.26%，查询缓存命中率 = 1.94%，命中率很差，可能写操作比较频繁吧，而且可能有些碎片。
查询缓存可以看做是SQL文本和查询结果的映射。如果第二次查询的SQL和第一次查询的SQL完全相同（注意必须是完全相同，即使多一个空格或者大小写不同都认为不同）且开启了查询缓存，那么第二次查询就直接从查询缓存中取结果，可以通过下面的SQL来查看缓存命中次数（是个累加值）：
另外即使完全相同的SQL，如果使用不同的字符集、不同的协议等也会被认为是不同的查询而分别进行缓存。
在表的结构或数据发生改变时，查询缓存中的数据不再有效。有这些INSERT、UPDATE、 DELETE、TRUNCATE、ALTER TABLE、DROP TABLE或DROP DATABASE会导致缓存数据失效。所以查询缓存适合有大量相同查询的应用，不适合有大量数据更新的应用。
可以使用下面三个SQL来清理查询缓存：
1、FLUSH QUERY CACHE; // 清理查询缓存内存碎片。
2、RESET QUERY CACHE; // 从查询缓存中移出所有查询。
3、FLUSH TABLES; //关闭所有打开的表，同时该操作将会清空查询缓存中的内容。
Query Cache是MySQL Server层的一个非常好的特性，对于小数据集或访问量非常集中的应用场景，有非常好的性能提升，但是Query Cache引入了一些新的问题，而且大部分场景下比较鸡肋，官方打算弃用了
参考：
我们都知道 MySQL 的 Table Cache 是表定义的缓存，江湖上流传着各种对这个参数的调优方法。
table cache 的作用，就是节约读取表结构文件的开销。对于table cache 是否命中，其实table cache 是针对于线程的，每个线程有自己的缓存，只缓存本线程的表结构定义。不过我们发现，strace 中没有关于表结构文件的 open 操作（只有 stat 操作，定位表结构文件是否存在），也就是说 table cache 不命中，不一定需要读取表结构文件。这种感觉好像是：在不命中 table cache 时，命中了另外一个表结构缓存。
运维建议：
我们读一下 MySQL 的文档，关于 table_open_cache 的建议值公式：建议值 = 最大并发数 * join 语句涉及的表的最大个数。
通过实验我们容易理解：table_cache 是针对于线程的，所以需要最大并发数个缓存。另外，一个语句 join 涉及的表，需要同时在缓存中存在。所以最小的缓存大小，等于语句 join 涉及的表的最大个数。将这两个数相乘，就得到了 MySQL 的建议值公式。