Oracle 5.0 Reference Manual page 724

Table of Contents

Advertisement

The query cache offers the potential for substantial performance improvement, but you should not
assume that it will do so under all circumstances. With some query cache configurations or server
workloads, you might actually see a performance decrease:
• Be cautious about sizing the query cache excessively large, which increases the overhead required
to maintain the cache, possibly beyond the benefit of enabling it. Sizes in tens of megabytes are
usually beneficial. Sizes in the hundreds of megabytes might not be.
• Server workload has a significant effect on query cache efficiency. A query mix consisting almost
entirely of a fixed set of
than a mix in which frequent
In some cases, a workaround is to use the
entering the cache for
"Query Cache
To verify that enabling the query cache is beneficial, test the operation of your MySQL server with the
cache enabled and disabled. Then retest periodically because query cache efficiency may change as
server workload changes.
8.6.3.1. How the Query Cache Operates
This section describes how the query cache works when it is operational.
Cache
Configuration", describes how to control whether it is operational.
Incoming queries are compared to those in the query cache before parsing, so the following two
queries are regarded as different by the query cache:
SELECT * FROM
Select * from
Queries must be exactly the same (byte for byte) to be seen as identical. In addition, query strings
that are identical may be treated as different for other reasons. Queries that use different databases,
different protocol versions, or different default character sets are considered different queries and are
cached separately.
Because comparison of a query against those in the cache occurs before parsing, the cache is not
used for queries of the following types:
• Prepared statements
• Queries that are a subquery of an outer query
• Queries executed within the body of a stored function or trigger
Before a query result is fetched from the query cache, MySQL checks whether the user has
privilege for all databases and tables involved. If this is not the case, the cached result is not used.
If a query result is returned from query cache, the server increments the
variable, not Com_select. See
If a table changes, all cached queries that use the table become invalid and are removed from the
cache. This includes queries that use
changed by many types of statements, such as INSERT, UPDATE, DELETE,
TABLE,
DROP
The query cache also works within transactions when using
In MySQL 5.0, the result from a
Before MySQL 5.0, a query that began with a leading comment could be cached, but could not be
fetched from the cache. This problem is fixed in MySQL 5.0.
The MySQL Query Cache
statements is much more likely to benefit from enabling the cache
SELECT
INSERT
statements that use frequently modified tables. (See
SELECT
Options".)
SELECT
tbl_name
tbl_name
Section 8.6.3.4, "Query Cache Status and
TABLE, or
DROP
DATABASE.
SELECT
statements cause continual invalidation of results in the cache.
SQL_NO_CACHE
tables that map to the changed table. A table can be
MERGE
InnoDB
query on a view is cached.
704
option to prevent results from even
Section 8.6.3.3, "Query
Qcache_hits
Maintenance".
TRUNCATE
tables.
Section 8.6.3.2,
SELECT
[530]
status
TABLE,
ALTER

Advertisement

Table of Contents
loading

This manual is also suitable for:

Mysql 5.0

Table of Contents