如何禁用 MySQL 查询缓存

How to disable MySQL Query Caching

提问by honor

I am trying to do some benchmarking of different queries on different columns but MySQL just won't let me do it. After the first execution of a query, I can never get the same execution time for that query again. For example if the query executes in 0.062 secs the first time, I can never get the same execution time for the 2nd, 3rd etc runs. It becomes either 0 seconds or something like 0.015.

我正在尝试对不同列的不同查询进行一些基准测试，但 MySQL 不让我这样做。在第一次执行查询之后，我再也无法获得该查询的相同执行时间。例如，如果查询第一次在 0.062 秒内执行，我永远无法获得第二次、第三次等运行的相同执行时间。它变成 0 秒或 0.015 之类的东西。

I have read many posts on disabling and clearing MySQL query cache but none of them has been of any help for me.

我已经阅读了许多关于禁用和清除 MySQL 查询缓存的帖子，但没有一篇对我有任何帮助。

like this SO post here

喜欢这个 所以在这里发帖

No matter what I do, MySQL seems to insist on using cached results.

无论我做什么，MySQL 似乎都坚持使用缓存结果。

I restart the MySQL Workbench then I run;

我重新启动 MySQL Workbench，然后运行；

set global query_cache_type=0;
set global query_cache_size=0;
flush query cache;
reset query cache;

The execution time keeps showing 0 secs.

执行时间一直显示0秒。

Only server variable that I haven't been able to change is "have_query_cache". Its value is "yes" and when I try to set it to "no" Workbench says it is read-only.

只有我无法更改的服务器变量是“have_query_cache”。它的值为“yes”，当我尝试将其设置为“no”时，Workbench 表示它是只读的。

I also do;

我也这样做；

set profiling=1;
run my select query
show profile for query 2;

Profiling result shows this:

分析结果显示：

'starting', '0.000077'
'checking permissions', '0.000007'
'Opening tables', '0.000016'
'init', '0.000035'
'System lock', '0.000009'
'optimizing', '0.000013'
'statistics', '0.000094'
'preparing', '0.000008'
'executing', '0.000002'
'Sending data', '0.000016'
'end', '0.000002'
'query end', '0.000003'
'closing tables', '0.000005'
'freeing items', '0.000139'
'cleaning up', '0.000009'

If I am not wrong this shows that no caches are being used right? But I stil see 0 secs. for the execution time.

如果我没有错，这表明没有使用缓存，对吗？但我仍然看到 0 秒。为执行时间。

Edit: The query I am running is a SELECT query using "SQL_NO_CACHE" like so:

编辑：我正在运行的查询是一个使用“SQL_NO_CACHE”的 SELECT 查询，如下所示：

SELECT SQL_NO_CACHE col1,now() from mytable where col2="some_value"

(I added now() function to help me prevent query caching)

（我添加了 now() 函数来帮助我防止查询缓存）

Edit2: I am using innoDB, MySQL 5.6.10

Edit2：我使用的是 innoDB，MySQL 5.6.10

Could someone please help me cause I can't see what is going on here.

有人可以帮助我，因为我看不到这里发生了什么。

Thanks a lot!

非常感谢！

采纳答案by Quassnoi

Running the query for the first time makes InnoDBbuffer pool populate with your tables' relevant blocks.

第一次运行查询会使InnoDB缓冲池填充表的相关块。

Since re-running the query requires exactly same blocks, it spares the query from the need to read them from disk when it's re-run, making it significantly faster.

由于重新运行查询需要完全相同的块，因此在重新运行时无需从磁盘读取它们，从而显着提高查询速度。

回答by ESG

This could be due to the cache of the data itself, and not the query cache.

这可能是由于数据本身的缓存，而不是查询缓存。

To make sure, you can disable the query cache for a single statement by adding SQL_NO_CACHEafter your SELECTstatement.

为了确保，您可以通过在SELECT语句之后添加SQL_NO_CACHE来禁用单个语句的查询缓存。

Ex:

前任：

SELECT SQL_NO_CACHE field FROM table.

SELECT SQL_NO_CACHE field FROM table.

回答by Bill Karwin

You can verify the difference between buffer pool page reads versus page reads that had to go to disk to get the page:

您可以验证缓冲池页面读取与必须转到磁盘以获取页面的页面读取之间的差异：

mysql> SHOW SESSION STATUS LIKE 'Innodb_buffer_pool_read%';
mysql> ...run a query...
mysql> SHOW SESSION STATUS LIKE 'Innodb_buffer_pool_read%';

Compare these values from the report, and note how much they grow:

比较报告中的这些值，并注意它们的增长程度：

+---------------------------------------+----------+
| Variable_name                         | Value    |
+---------------------------------------+----------+
| Innodb_buffer_pool_read_requests      | 10327490 |
| Innodb_buffer_pool_reads              | 1133     |
+---------------------------------------+----------+

The read_requestsare logical page reads, which may read from pages already in the buffer pool. If this number grows after your query, but readsdoesn't grow, then your query got its result solely from the buffer pool.

该read_requests是逻辑页读取，可以从网页已经在缓冲池读取。如果此数字在您的查询后增长，但读取数没有增长，则您的查询仅从缓冲池中获得其结果。

The readsare the number of page reads that had to go out to disk and incur the cost of I/O to copy pages into the buffer pool. If this number grows after your query, then it had to load data from disk.

该读取是页面的读取数不得不出去到磁盘和承担的I / O成本页面复制到缓冲池。如果这个数字在您查询后增长，那么它必须从磁盘加载数据。

For more on the difference between the performance of memory access versus disk access, read http://everythingisdata.wordpress.com/2009/10/17/numbers-everyone-should-know/

有关内存访问与磁盘访问性能之间差异的更多信息，请阅读http://everythingisdata.wordpress.com/2009/10/17/numbers-everyone-should-know/

---

---

Re your comment:

回复您的评论：

The "Opening tables" is related to an in-memory cache of InnoDB tables, kind of like a data dictionary. Tables are opened the first time they are referenced after a restart. A given table's entry in the in-memory data dictionary stays in memory indefinitely, so that memory usage can grow pretty large if you have thousands of tables. In MySQL 5.6, they have some ne tuning variables to put a cap on that memory usage, and evict infrequently-used tables. But this whole mechanism is separate from the buffer pool, which stores pages of data and indexes.

“打开表”与 InnoDB 表的内存缓存相关，有点像数据字典。表在重新启动后第一次被引用时打开。内存数据字典中给定表的条目会无限期地保留在内存中，因此如果您有数千个表，内存使用量会变得非常大。在 MySQL 5.6 中，他们有一些新的调整变量来限制内存使用量，并驱逐不常用的表。但是整个机制与缓冲池是分开的，缓冲池存储数据和索引的页面。

The "statistics" is also separate from the buffer pool. InnoDB maintains in-memory statistics about data and indexes, which it uses to guide the query optimizer. Statistics are refreshed automatically when you first access an InnoDB table, when you run SHOW TABLE STATUS or run certain queries against the INFORMATION_SCHEMA, when you run ANALYZE TABLE, and also when the size of the table changes significantly. InnoDB generates these statistics reading a fixed number of pages from the table at random, and this is likely to hit the disk if you have a cold buffer pool.

“统计”也与缓冲池分开。InnoDB 维护有关数据和索引的内存统计信息，用于指导查询优化器。当您第一次访问 InnoDB 表时，当您运行 SHOW TABLE STATUS 或对 INFORMATION_SCHEMA 运行某些查询时，当您运行 ANALYZE TABLE 时，以及当表的大小发生显着变化时，统计信息会自动刷新。InnoDB 生成这些统计信息，随机从表中读取固定数量的页面，如果您有冷缓冲池，这很可能会命中磁盘。

回答by honor

OK. So I have been diggin' on this innoDB buffer pool issue. Thank you @Quassnoi, @TheVedge for mentioning that. It has been very useful for the following work.

好的。所以我一直在研究这个 innoDB 缓冲池问题。谢谢@Quassnoi、@TheVedge 提到这一点。对接下来的工作很有帮助。

I was trying to find a way to disable or reset innoDB buffer pool but I haven't been able to find a way other than restarting MySQL server. (To restart the server on a windows box you can either use services.msc or command prompt.)

我试图找到一种禁用或重置 innoDB 缓冲池的方法，但除了重新启动 MySQL 服务器之外，我找不到其他方法。（要在 Windows 机器上重新启动服务器，您可以使用 services.msc 或命令提示符。）

I guess all the configuration variable settings and the use of "SQL_NO_CACHE" was more than enough to avoid cache use, and also checking the profiling results I was not seeing any cache reference neither (check the original post).

我猜所有配置变量设置和“SQL_NO_CACHE”的使用足以避免缓存使用，并且还检查分析结果我也没有看到任何缓存引用（查看原始帖子）。

Then I decided to check the profiling for the same query's 1st and 2nd runs after restarting MySQL server. This way I would be able to see what was going on during the query execution step by step.

然后我决定在重新启动 MySQL 服务器后检查相同查询的第一次和第二次运行的分析。这样我就可以一步一步地看到查询执行过程中发生了什么。

1st run after server restart yielded the following steps and timings:

服务器重启后的第一次运行产生以下步骤和时间：

'starting', '0.000078'
'checking permissions', '0.000005'
'Opening tables', '0.120329'
'init', '0.000107'
'System lock', '0.000012'
'optimizing', '0.000024'
'statistics', '0.065317'
'preparing', '0.000026'
'executing', '0.000003'
'Sending data', '0.000038'
'end', '0.000005'
'query end', '0.000006'
'closing tables', '0.000014'
'freeing items', '0.000463'
'cleaning up', '0.000039'

And these are the results of the 2nd run:

这些是第二次运行的结果：

'starting', '0.000068'
'checking permissions', '0.000006'
'Opening tables', '0.000019'
'init', '0.000046'
'System lock', '0.000007'
'optimizing', '0.000010'
'statistics', '0.000073'
'preparing', '0.000009'
'executing', '0.000002'
'Sending data', '0.000035'
'end', '0.000003'
'query end', '0.000003'
'closing tables', '0.000006'
'freeing items', '0.000181'
'cleaning up', '0.000015'

As you can see there is a huge difference for the durations of "opening tables" and "statistics" actions between the two executions and none of the executions reference any cache.

正如您所看到的，两次执行之间“打开表”和“统计”操作的持续时间存在巨大差异，并且没有一次执行引用任何缓存。

The two actions seem to be the most time consuming parts for the 1st execution (I believe as a part of the creation of innoDB buffer pool), and once the pool is generated these two actions not performed as heavily hence the much shorter execution time for the query after the buffer pool creation.

这两个动作似乎是第一次执行最耗时的部分（我相信这是创建 innoDB 缓冲池的一部分），并且一旦生成了缓冲池，这两个动作就不会被大量执行，因此执行时间要短得多创建缓冲池后的查询。

When you sum up the execution times of the individual steps for 2nd run we get 0.000483 seconds and I think MySQL workbench shows this result as 0.000 secs which might also trick you to think that the second run was result of cache using but actually it seems like it is not. This is just a display precision issue for the execution durations of queries.

当您总结第二次运行的各个步骤的执行时间时，我们得到 0.000483 秒，我认为 MySQL 工作台将此结果显示为 0.000 秒，这也可能会让您认为第二次运行是缓存使用的结果，但实际上看起来像它不是。这只是查询执行持续时间的显示精度问题。

As a result what I have figured out so far is I actually have been able to disable the use of caches and it is the completion of innoDB buffer pool that speeds up the second query so much. This also means that I can find a record in 2 million rows in 0.000483 seconds.

因此，到目前为止我发现的是我实际上已经能够禁用缓存的使用，并且 innoDB 缓冲池的完成大大加快了第二个查询的速度。这也意味着我可以在 0.000483 秒内找到 200 万行的记录。

Would you agree?

你会同意吗？

回答by Wilson Hauck

In your .ini/.cfg in [mysqld] section, add a line have_query_cache=0 # to prevent using resources from default of yes ccyy/mm/dd your initials. With your other changes, close/restart MySQL. You should NOT observe any QC activity in profile research.

在 [mysqld] 部分的 .ini/.cfg 中，添加一行have_query_cache=0 # to prevent using resources from default of yes ccyy/mm/dd your initials。使用其他更改，关闭/重新启动 MySQL。您不应在配置文件研究中观察任何 QC 活动。