Consultas são comparadas antes da análise, logo
SELECT * FROM nome_tabela
e
Select * from nome_tabela
são consideradas consultas diferentes pela cache de consulta, assim consultas precisam ser exatamente a mesma (byte a byte) para serem vistas como idênticas. Além disso, uma consulta pode ser vista como diferente se, por exemplo, um cliente estiver usando um novo formato de protocolo de comunicação ou um conjunto de caracteres diferente de outro cliente.
Cansultas que utilizam banco de dados diferentes, utilizam versões de protocolos diferentes ou que usam conjunto de caracters padrão diferentes são considerados consultas diferentes e armazenadas separadamente.
A cache funciona para consultas do tipo SELECT
SQL_CALC_FOUND_ROWS ...
e SELECT FOUND_ROWS()
...
porque o número de registros encontrados também
é armazenado na cache.
Se o resultado da consulta foi retornado da cache de consultas,
então o estado da variável Com_select
não
irá ser aumentado, mas Qcache_hits
será.
See Secção 6.9.4, “Estado e Manutenção da Cache de Consultas”.
Se uma tabela é alterada (INSERT
,
UPDATE
, DELETE
,
TRUNCATE
, ALTER
ou
DROP TABLE|DATABASE
), então todas as caches
de consulta que utilizam esta tabela (possivelmente atarvés de
uma tabela MRG_MyISAM
!) se torna inválida e
é removida da cache.
Tabelas InnoDB
transacionais que foram
alteradas serão invalidadas quando um COMMIT
é realizado.
No MySQL 4.0 a cache de consulta está disbilitada dentro da
transação (ela não retorna resultados), mas a partir da
versão 4.1.1 as caches de consultas funcionarão com tabelas
InnoDB
dentro da transação (ela usará o
número da versão da tabela para detectar se a data é atual ou
não).
Antes da versão 5.0, consultas com comentários na mesma linha não podem ser trazidas da cache (mas elas serão colocadas na cache se satisfazerem outras condições).
Uma consulta não pode ser armazenada em cache se contem uma das funções:
Função | Função | Função |
Funções Definidas por Usuarios |
CONNECTION_ID |
FOUND_ROWS |
GET_LOCK |
RELEASE_LOCK |
LOAD_FILE |
MASTER_POS_WAIT |
NOW |
SYSDATE |
CURRENT_TIMESTAMP |
CURDATE |
CURRENT_DATE |
CURTIME |
CURRENT_TIME |
DATABASE |
ENCRYPT (com um parâmetro) |
LAST_INSERT_ID |
RAND |
UNIX_TIMESTAMP (sem parâmetros) |
USER |
BENCHMARK |
Um consulta não pode ser armazenada em cache se conter
variáveis, referenciar o banco de dados do sistema mysql, for
da forma SELECT ... IN SHARE MODE
,
SELECT ... INTO OUTFILE ...
, SELECT
... INTO DUMPFILE ...
ou da forma SELECT *
FROM AUTOINCREMENT_FIELD IS NULL
(para retornar a ID
da ultima inserção - ODBC contorna este problema).
No entanto, FOUND_ROWS()
retornará o valor
correto, mesmo se a consulta precedente foi buscada da cache.
No caso de uma consulta não utilizar qualquer tabela, ou utilizar tabelas temporárias, ou se o usuário tiver um privilégio de coluna para qualquer tabela chamada, esta consulta não será armazenada em cache.
Antes de uma consulta ser trazida da cache de consulta, o MySQL irá verificar se o usuário com privilégio SELECT para todos os banco de dados e tabelas envolvidos. Se este não for o caso, o resultado em cache não será usado.
This is a translation of the MySQL Reference Manual that can be found at dev.mysql.com. The original Reference Manual is in English, and this translation is not necessarily as up to date as the English version.