昨天发现一个很奇怪的问题，运营说有一条帖子已经删除了，但是还是显示，显示发现有文件缓存，删除后还是会生成，怀疑是数据库里没有被删除。进数据库一看，表坏了，根本没有办法进行任何操作（奇怪）。没办法，先修表，修好后通过phpmyadmin查询没有改记录，进shell下也找不到（有点意思）。于是分析程序，程序确可以把数据查出来（邪了）。直接把程序里的sql在mysql里执行，出数据了（有点眉目了），怀疑是mysql缓存的问题。有点不明白，数据库里肯定没有那条数据了，说明执行了delete，但为什么缓存还生效呢？不管了，先重启数据库，问题解决。
从网上查了下缓存的资料，简单的介绍一下
缓存机制简单的说就是缓存sql文本及查询结果，如果运行相同的sql，服务器直接从缓存中取到结果，而不需要再去解析和执行sql。如果表更改 了，那么使用这个表的所有缓冲查询将不再有效，查询缓存值的相关条目被清空。更改指的是表中任何数据或是结构的改变，包括INSERT、UPDATE、 DELETE、TRUNCATE、ALTER TABLE、DROP TABLE或DROP DATABASE等，也包括那些映射到改变了的表的使用MERGE表的查询。显然，这对于频繁更新的表，查询缓存是不适合的，而对于一些不常改变数据且有 大量相同sql查询的表，查询缓存会节约很大的性能。
查询必须是完全相同的(逐字节相同)才能够被认为是相同的。另外，同样的查询字符串由于其它原因可能认为是不同的。使用不同的数据库、不同的协议版本或者不同 默认字符集的查询被认为是不同的查询并且分别进行缓存。
下面sql查询缓存认为是不同的：
SELECT * FROM tbl_name
Select * from tbl_name
查询缓存相关参数
+——————————+———+
| Variable_name | Value |
+——————————+———+
| have_query_cache | YES | –查询缓存是否可用
| query_cache_limit | 1048576 | –可缓存具体查询结果的最大值
| query_cache_min_res_unit | 4096 |
| query_cache_size | 599040 | –查询缓存的大小
| query_cache_type | ON | –阻止或是支持查询缓存
| query_cache_wlock_invalidate | OFF |
+——————————+———+
下面是一个简单的例子：
Enter password:
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 3
Server version: 5.0.45-community MySQL Community Edition (GPL)
Type ‘help;’ or ‘\h’ for help. Type ‘\c’ to clear the buffer.
mysql> set global query_cache_size = 600000; –设置缓存内存
Query OK, 0 rows affected (0.00 sec)
mysql> set session query_cache_type = ON; –开启查询缓存
Query OK, 0 rows affected (0.00 sec)
mysql> use test
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A
Database changed
mysql> show tables;
+—————-+
| Tables_in_test |
+—————-+
| animals |
| person |
+—————-+
5 rows in set (0.00 sec)
mysql> select count(*) from animals;
+———-+
| count(*) |
+———-+
| 6 |
+———-+
1 row in set (0.00 sec)
–Qcache_hits表示sql查询在缓存中命中的累计次数，是累加值。
mysql> SHOW STATUS LIKE ‘Qcache_hits’;
+—————+——-+
| Variable_name | Value |
+—————+——-+
| Qcache_hits | 0 | –0次
+—————+——-+
8 rows in set (0.00 sec)
mysql> select count(*) from animals;
+———-+
| count(*) |
+———-+
| 6 |
+———-+
1 row in set (0.00 sec)
mysql> SHOW STATUS LIKE ‘Qcache%’;
+—————+——-+
| Variable_name | Value |
+—————+——-+
| Qcache_hits | 1 | –表示sql在缓存中直接得到结果，不需要再去解析
+—————+——-+
8 rows in set (0.00 sec)
mysql> select count(*) from animals;
+———-+
| count(*) |
+———-+
| 6 |
+———-+
1 row in set (0.00 sec)
mysql> select count(*) from animals;
+———-+
| count(*) |
+———-+
| 6 |
+———-+
1 row in set (0.00 sec)
mysql> SHOW STATUS LIKE ‘Qcache_hits’;
+—————+——-+
| Variable_name | Value |
+—————+——-+
| Qcache_hits | 3 | –上面的sql也是是从缓存中直接取到结果
+—————+——-+
1 row in set (0.00 sec)
mysql> insert into animals select 9,’testsds’ ; –插入数据后，跟这个表所有相关的sql缓存就会被清空掉
Query OK, 1 row affected (0.00 sec)
Records: 1 Duplicates: 0 Warnings: 0
mysql> select count(*) from animals;
+———-+
| count(*) |
+———-+
| 7 |
+———-+
1 row in set (0.00 sec)
mysql> SHOW STATUS LIKE ‘Qcache_hits’;
+—————+——-+
| Variable_name | Value |
+—————+——-+
| Qcache_hits | 3 | –还是等于3，说明上一条sql是没有直接从缓存中直接得到的
+—————+——-+
1 row in set (0.00 sec)
mysql> select count(*) from animals;
+———-+
| count(*) |
+———-+
| 7 |
+———-+
1 row in set (0.00 sec)
mysql> SHOW STATUS LIKE ‘Qcache_hits’;
+—————+——-+
| Variable_name | Value |
+—————+——-+
| Qcache_hits | 4 |
+—————+——-+
1 row in set (0.00 sec)
我是从07年12月开始学习mysql的，断断续续看了一小部分。一直想写个mysql入门的系列，包括mysql的安装，配置再到优化，复制，集群等等，唉，懒哪，什么都没有整理出来，希望年后能有所进展。
参考：
http://dev.mysql.com/doc/refman/5.1/zh/
FROM：http://rdc.taobao.com/blog/dba/html/61_mysql_select_cache.html
附：
查询缓存的统计信息
mysql> SHOW STATUS LIKE ‘qcache%’;
Qcache_free_blocks 缓存中相邻内存块的个数。数目大说明可能有碎片。FLUSH QUERY CACHE 会对缓存中的碎片进行整理，从而得到一个空闲块。
Qcache_free_memory 缓存中的空闲内存。
Qcache_hits 每次查询在缓存中命中时就增大。
Qcache_inserts 每次插入一个查询时就增大。命中次数除以插入次数就是不中比率；用 1 减去这个值就是命中率。在上面这个例子中，大约有 87% 的查询都在缓存中命中。
Qcache_lowmem_prunes 缓存出现内存不足并且必须要进行清理以便为更多查询提供空间的次数。这个数字最好长时间来看；如果这个数字在不断增长，就表示可能碎片非常严重，或者内存很少。（上面的 free_blocks 和 free_memory 可以告诉您属于哪种情况）。
Qcache_not_cached 不适合进行缓存的查询的数量，通常是由于这些查询不是 SELECT 语句。
Qcache_queries_in_cache 当前缓存的查询（和响应）的数量。
Qcache_total_blocks 缓存中块的数量。通常，间隔几秒显示这些变量就可以看出区别，这可以帮助确定缓存是否正在有效地使用。运行 FLUSH STATUS 可以重置一些计数器，如果服务器已经运行了一段时间，这会非常有帮助。
有点不明白，数据库里肯定没有那条数据了，说明执行了delete，但为什么缓存还生效呢？
–博主现在能解释这一现象吗？既然已经delete，其缓存应该失效不可再被访问，为何还能查出来？
另外，如果现在再遇到此问题，博主能否阐述一下troubleshooting思路，还是继续重启数据库吗? 毕竟flush query cache无法清空cache