When to use SQL_NO_CACHE

Question

I am in the process of going over my queries, and I have been reading articles about how you should use SQL_NO_CACHE in SELECT queries. This has co

Answer 1

In order to answer you question you first have to understand how the MySQL query cache works. A very good article about this can be found here. On of the key aspects is that the cache is synchronized with the data:

The query cache does not return stale data. When tables are modified, any relevant entries in the query cache are flushed.

In your usecases I don't find any real purpose for not using the query cache with SQL_NO_CACHE. There are reasons like profiling or avoiding writing big data into a limited query cache for using this option, but I don't see this to be the case here.

Answer 2

SQL_NO_CACHE

---

Simply add SQL_NO_CACHE after the SELECT part of the SELECT statement and before the fields list. The first query below will use the query cache if it is enabled and the query is cached:

SELECT * FROM table WHERE search= 'keyword'; //lets take 1ms

The second query below will not use the query cache:

SELECT SQL_NO_CACHE * FROM table WHERE search= 'keyword'; //lets take ~0.2ms at 2nd time

This is particularly useful when benchmarking a query; if the query cache is enabled although the first query may take some time the second and subsequent queries are almost instant. With the use of SQL_NO_CACHE you can be assured the query cache is not used and can safely compare result times. The SQL_NO_CACHE hint turns off MySQL's builtin query caching mechanism for a particular query. You can help MySQL make the query cache more efficent by using this hint on queries that are highly dynamic (such as a keyword search, or a report that only runs nightly). Make sure query caching is turned on otherwise there is no need for this command.

what SQL_CACHE and SQL_NO_CACHE ?

The SQL_CACHE and SQL_NO_CACHE options affect caching of query results in the query cache. SQL_CACHE tells MySQL to store the result in the query cache if it is cacheable and the value of the query_cache_type system variable is 2 or DEMAND. With SQL_NO_CACHE, the server does not use the query cache. It neither checks the query cache to see whether the result is already cached, nor does it cache the query result. (Due to a limitation in the parser, a space character must precede and follow the SQL_NO_CACHE keyword; a nonspace such as a newline causes the server to check the query cache to see whether the result is already cached.)

NO_CACHE according to my opinion can be used if 'CACHE' is enabled and the data in the db is dynamically updated , ie db data cache can't be relied upon , eg: storing user password hash we cant rely on CACHE since there is frequent possibility of a change of data

Updates of useful scenarios

---

1) force not to use cache for testing speed of query

Answer 3

The most obvious time I would choose to suppress caching is when I don't want the query results in the cache (obviously?).

If I will only be running a query once then there's no point in displacing data currently in the cache to make room for data which will never be retreived from the cache.

The second scenario is where I want to run a low priority query - e.g. generating a report or a partial backup - where the performance of my query is not important, but it is important that it is minimaly disruptive for the other stuff happening in the database (there are some issues around contention for cache access).

A third scenario is when there are lots of simple, single table select queries returning very small datasets (e.g. using trivial ORM). In this scenario, using query caching will likely be slower than bypassing it altogether - the DBMS will spend more time managing the query cache than reading the data from buffer pool / system cache.

As Tot says, the cache will skew any profiling / benchmarking - but the query cache is not the only place where the data is bufferred/cached.

You select some data from table a in order to update a field in table b, should you use SQL_NO_CACHE on the select for table a?

No. The cache is automatically invalidated when the underlying data is modified (which is where much of the cost for simple queries comes from).

Answer 4

The only time I used it was when profiling queries (EXPLAIN extended...).

When running a query several times (a very import step to "warm up" the server), it will be cached therefore the profiler will output wrong results.

Depending of the situation I also use:

SET SESSION query_cache_type = OFF