Mysql SQL\u NO\u缓存不工作

第一次运行此sql需要39秒，当我再次运行并增加sql\u NO\u缓存时，似乎没有生效：

mysql> select count(*) from `deal_expired` where `site`=8&&`area`=122 && 
endtime<1310444996056;
+----------+
| count(*) |
+----------+
|      497 |
+----------+
1 row in set (39.55 sec)

mysql> select SQL_NO_CACHE count(*) from `deal_expired` where `site`=8&&`area`=
122 && endtime<1310444996056;
+----------+
| count(*) |
+----------+
|      497 |
+----------+
1 row in set (0.16 sec)

---

解释此SQL，使用site+endtime复合索引（命名site\u endtime）：

mysql>解释从'deal\u expired'中选择count（*），其中'site`=8&&'area`=122&&endti
我
见：
您可以尝试
重置查询缓存
（您需要重新加载权限），尽管刚刚读取了上面的链接，这可能也不起作用：(
“如何获得相同的SQL运行时？”的答案是-您不能。
如果您的查询读取了一些行，它们将被缓存，具体取决于正在使用的存储引擎，这些行要么在OS缓存（myisam）中，要么在缓冲池（innodb）中。如果缓存行，则第二次运行相同的查询速度要快得多，因为MySQL不必从磁盘读取数据。
我的印象是，包含任何在当前运行时计算的SQL函数都不会缓存。您是否尝试过以下操作

select count(*), now() from `deal_expired` where `site`=8&&`area`=122 && endtime<1310444996056;

select count（*），now（）来自'deal\u expired'，其中'site`=8&&&`area`=122&&endtime第一个查询应该使用SQL\u NO\u缓存来告诉MySQL不要将结果放入缓存。第二个查询使用缓存，并告诉MySQL不要缓存该查询的结果，这没有任何作用

tl；dr-反转您的查询。
我没有办法对此进行优化以运行39秒sql？即使重新启动mysql，如果索引/数据文件位于操作系统文件/块缓存中，也可能无法将其删除。通常，“优化”意味着运行得更快：）我没有看到很多人要求降低运行速度。如果您使用的是MyISAM，您可能会运气不佳，但是如果在Linux上使用Innodb，Innodb_flush_method=O_DIRECT应该避免在文件系统中缓存。在Linux上，您还可以执行
echo 3>/proc/sys/vm/drop_caches
来清除操作系统缓存。SQL_NO_cache告诉MySQL不要将结果放入缓存。因此，只有在第一次执行特定查询后使用SQL\u NO\u缓存时，才能获得预期的结果。因此Mysql从未在缓存中找到结果我尝试过，
RESET QUERY CACHE
和
FLUSH TABLES
，
SET SESSION QUERY\u CACHE\u type=off
是否使用复合索引进行此查询？@Karolis有一个site+endtime（名为
site\u endtime
）复合索引我对您的特定数据库一无所知，但似乎最好创建另一个复合索引（site+area+endtime）。MySql将读取更少的行，因此它应该会变得更快。@Karolis，谢谢，我将创建
expired
布尔字段（0和1），并将我的SQL查询更改为：
site=？&&area=？&&expired=1
并创建site+area+expired复合索引，这比
site=？&&area=？&&endtimes好吗？我认为两者之间应该没有太大区别（site+area+endtime）和（site+area+expired）。但是您可以测试它。我不明白为什么这不是正确答案。应该是。根据第二次选择时的
SQL\u NO\u缓存
应该跳过检查查询缓存，因此不需要上面的内容：服务器不使用查询缓存。它既不检查查询缓存以查看结果是否已缓存，也不缓存查询结果。"此答案不正确，因为使用
SQL\u NO\u CACHE
的查询也永远不会得到来自查询缓存的响应。在SQL解析器运行之前，使用查询的精确字节进行匹配，检查查询缓存。除非对由完全相同字节组成的查询的响应已经在缓存中，否则不可能存在由于使用
SQL\u NO\u CACHE
的查询的结果永远不会写入查询缓存，因此无法从缓存中提供该结果。
SQL\u NO\u CACHE
因此保证按照OP的预期运行，从不从缓存中提供响应。这对我来说不起作用，使用SQL\u NO\u CACHE的第一次查询花了2分钟，不是吗他第二次使用SQL NO_缓存花了15秒，这对我帮助很大。谢谢。
mysql> SHOW STATUS LIKE "Qcache%";
+-------------------------+-------+
| Variable_name           | Value |
+-------------------------+-------+
| Qcache_free_blocks      | 0     |
| Qcache_free_memory      | 0     |
| Qcache_hits             | 0     |
| Qcache_inserts          | 0     |
| Qcache_lowmem_prunes    | 0     |
| Qcache_not_cached       | 0     |
| Qcache_queries_in_cache | 0     |
| Qcache_total_blocks     | 0     |
+-------------------------+-------+
8 rows in set (0.04 sec)

mysql> select count(*) from `deal_expired` where `site`=25&&`area`=134 && endtime<1310
483196227;
+----------+
| count(*) |
+----------+
|      315 |
+----------+
1 row in set (0.01 sec)

mysql> SHOW STATUS LIKE "Qcache%";
+-------------------------+-------+
| Variable_name           | Value |
+-------------------------+-------+
| Qcache_free_blocks      | 0     |
| Qcache_free_memory      | 0     |
| Qcache_hits             | 0     |
| Qcache_inserts          | 0     |
| Qcache_lowmem_prunes    | 0     |
| Qcache_not_cached       | 0     |
| Qcache_queries_in_cache | 0     |
| Qcache_total_blocks     | 0     |
+-------------------------+-------+
8 rows in set (0.00 sec)

mysql> explain select count(*) from `deal_expired` where `site`=8&&`area`=122 && endti
me<1310444996056;
+--------+------+-------------------------------+--------------+---------+------
-+------+-------------+
| table  | type | possible_keys                 | key          | key_len | ref
 | rows | Extra       |
+--------+------+-------------------------------+--------------+---------+------
-+------+-------------+
| deal_expired | ref  | name,url,endtime,site_endtime | site_endtime |       4 | const
 |  353 | Using where |
+--------+------+-------------------------------+--------------+---------+------
-+------+-------------+
1 row in set (0.00 sec)

select count(*), now() from `deal_expired` where `site`=8&&`area`=122 && endtime<1310444996056;