O Fast Query Cache é um cache de consultas desenvolvido pela Alibaba Cloud que substitui o cache nativo do MySQL por um design sem bloqueios e de alta concorrência. Esse recurso aumenta significativamente as consultas por segundo (QPS) em cargas de trabalho com predominância de leitura e adiciona sobrecarga mínima em cenários mistos de leitura e escrita.
O Fast Query Cache está disponível apenas em instâncias RDS com MySQL 5.7 e versão secundária do mecanismo 20200331 ou posterior. Além disso, exige a desativação do service de proxy dedicado.
Pré-requisitos
Antes de começar, verifique se:
Sua instância RDS executa o MySQL 5.7 com versão secundária do mecanismo 20200331 ou posterior.
O service de proxy dedicado está desativado na sua instância RDS. Para mais detalhes, consulte Disable the dedicated proxy service for an ApsaraDB RDS for MySQL instance.
Como funciona
Um cache de consultas melhora o desempenho ao armazenar conjuntos de resultados de consultas elegíveis. Quando a mesma consulta é executada novamente, o banco de dados retorna diretamente o resultado em cache. Isso ignora a análise, a otimização e a execução do SQL, reduzindo a sobrecarga da CPU e o tempo de resposta para consultas simples e frequentes.
Por que não usar o cache de consultas nativo do MySQL?
O cache de consultas nativo do MySQL usa um bloqueio global em todas as operações. Sob alta concorrência, esse bloqueio torna-se um gargalo: adicionar mais núcleos de CPU pode reduzir o QPS em vez de aumentá-lo. O gerenciamento inadequado de memória agrava o problem, pois a fragmentação se acumula, a recuperação é lenta e baixas taxas de acerto causam degradação significativa do desempenho. Esses problemas levaram o MySQL a remover completamente o cache de consultas nativo na versão 8.0 e a desativá-lo por padrão nas versões anteriores.
Como o Fast Query Cache resolve esses problemas
A Alibaba Cloud redesenhou o cache de consultas desde a base:
|
Área de melhoria |
O que mudou |
|
Concorrência |
Remoção do bloqueio global. Adota um design sem bloqueios com sharding, permitindo processamento paralelo multicore real sem contenção. |
|
Gerenciamento de memória |
Alocação de memória sob demanda. Políticas inteligentes de recuperação reduzem a fragmentação e melhoram a utilização. |
|
Política de cache |
Monitoramento da taxa de acerto em tempo real. Ajusta dinamicamente a política de evicção e o período de validade para evitar que entradas obsoletas ocupem recursos. |
|
Compatibilidade de escrita |
Invaliação incremental. Invalida parcialmente apenas as entradas afetadas por uma escrita, reduzindo o impacto nas leituras em cache. |
Ative o Fast Query Cache
Dois parâmetros controlam o Fast Query Cache: query_cache_type (interruptor liga/desliga) e query_cache_size (alocação de memória).
Parâmetros
|
Parâmetro |
Descrição |
|
|
Controla o interruptor do cache. Valores válidos: 0 — desativado (padrão); 1 — ativado para todas as consultas elegíveis ( |
|
|
Memória alocada para o cache. Valores válidos: 0 a 10.485.760.000 bytes (deve ser múltiplo de 1.024). Unidade: bytes. |
Etapas
Como o Fast Query Cache consome memória extra, reconfigure primeiro o innodb_buffer_pool_size para liberar espaço:
Reduza o
innodb_buffer_pool_sizepara 90% do valor atual. Os 10% liberados ficam disponíveis para o cache de consultas. Por exemplo, se o valor atual for{DBInstanceClassMemory*7/10}, defina-o como{DBInstanceClassMemory*63/100}. Para mais detalhes, consulte Change the size of the InnoDB buffer pool.-
Defina o
query_cache_sizecom base na sua carga de trabalho. Para detalhes sobre modificação de parâmetros, consulte Modify instance parameters.Se souber o tamanho do conjunto de resultados: defina o
query_cache_sizecomo 20% do tamanho do conjunto de resultados.Se não souber o tamanho do conjunto de resultados: defina o
query_cache_sizecomo 10% of `innodb_buffer_pool_size`.
ImportanteAo redimensionar sua instância RDS, o
query_cache_sizenão escala automaticamente. Reconfigure-o imediatamente após a alteração de especificação entrar em vigor. Defina o
query_cache_typecomo 1 para ativar o Fast Query Cache. Para mais detalhes, consulte Modify instance parameters.
Testar no nível de sessão
Antes de alterar a configuração global, teste o Fast Query Cache em uma única conexão sem afetar outros usuários:
-- Enable Fast Query Cache for this session only
SET SESSION query_cache_type = 1;
-- Disable Fast Query Cache for this session only
SET SESSION query_cache_type = 0;
Verifique se o cache está funcionando
Após ativar o Fast Query Cache, execute a seguinte instrução para verificar a atividade do cache:
SHOW STATUS LIKE 'Qcache%';
Principais métricas para análise:
|
Métrica |
O que indica |
|
|
Número de consultas atendidas pelo cache. Um valor crescente confirma que o cache está ativo. |
|
|
Número de consultas adicionadas ao cache. |
|
|
Número de entradas removidas devido à pressão de memória. Um valor alto significa que o |
|
|
Número de consultas não armazenadas em cache (tipos inelegíveis ou uso de |
Um cache saudável apresenta Qcache_hits crescendo mais rápido que Qcache_inserts.
Benchmarks de desempenho
Os benchmarks a seguir comparam o QPS em três configurações em uma instância RDS dedicada (4 núcleos de CPU, 8 GB de memória, 250 MB de dados de teste usando Sysbench):
QC-OFF: sem cache de consultas
MySQL-QC: cache de consultas nativo do MySQL
Fast-QC: Fast Query Cache
Carga de trabalho de leitura com acerto total (taxa de acerto de 100%, cache de 512 MB)
Usa o script oltp_point_select com instruções POINT SELECT em chaves primárias.
Tabela 1. QPS para consultas de leitura com taxa de acerto de cache de 100%
|
Número de consultas simultâneas |
QC-OFF |
MySQL-QC (aumento de QPS comparado ao QC-OFF) |
Fast-QC (aumento de QPS comparado ao QC-OFF) |
|
1 |
8.093 |
8.771 (8,38%) |
9.261 (14,43%) |
|
8 |
62.262 |
65.686 (5,50%) |
75.313 (20,96%) |
|
16 |
97.083 |
73.027 (-24,78%) |
139.323 (43,51%) |
|
32 |
97.337 |
60.567 (-37,78%) |
200.978 (106,48%) |
|
64 |
106.283 |
60.216 (-43,34%) |
221.659 (108,56%) |
|
128 |
107.781 |
62.844 (-41,69%) |
231.409 (114,70%) |
|
256 |
106.694 |
63.832 (-40,17%) |
222.187 (108,25%) |
|
512 |
101.733 |
64.866 (-36,24%) |
203.789 (100,32%) |
|
1.024 |
89.548 |
62.291 (-30,44%) |
203.542 (127,30%) |

À medida que a concorrência aumenta, o QPS do cache nativo do MySQL cai drasticamente — chegando a 43% com 64 threads. Já o QPS do Fast Query Cache continua subindo, superando o QC-OFF em até 127% com 1.024 threads.
Carga de trabalho de leitura com alta taxa de acerto (>80% de taxa de acerto, cache de 512 MB)
Usa o script oltp_read_only com consultas de intervalo que retornam vários registros.
Tabela 2. QPS para consultas de leitura com taxa de acerto de cache superior a 80%
|
Número de consultas simultâneas |
QC-OFF |
MySQL-QC (aumento de QPS comparado ao QC-OFF) |
Fast-QC (aumento de QPS comparado ao QC-OFF) |
|
1 |
5.099 |
6.467 (26,83%) |
7.022 (37,71%) |
|
8 |
28.782 |
28.651 (-0,46%) |
45.017 (56,41%) |
|
16 |
35.333 |
31.099 (-11,98%) |
66.770 (88,97%) |
|
32 |
34.864 |
27.610 (-20,81%) |
67.623 (93,96%) |
|
64 |
35.503 |
27.518 (-22,49%) |
75.981 (114,01%) |
|
128 |
35.744 |
27.733 (-22,41%) |
80.396 (124,92%) |
|
256 |
35.685 |
27.738 (-22,27%) |
80.925 (126,78%) |
|
512 |
35.308 |
27.398 (-22,40%) |
79.323 (124,66%) |
|
1.024 |
34.044 |
26.861 (-22,10%) |
75.742 (122,48%) |

O QPS do Fast Query Cache continua aumentando com a concorrência e atinge um pico superior a 124% acima do QC-OFF. O cache nativo do MySQL degrada para 22% abaixo do QC-OFF sob alta concorrência.
Carga de trabalho de leitura com baixa taxa de acerto (~10% de taxa de acerto, cache de 16 MB)
Usa o script oltp_read_only. Um cache de 16 MB é muito menor que o conjunto de dados, causando evicções frequentes e uma taxa de acerto próxima de 10%.
Tabela 3. QPS para consultas de leitura com taxa de acerto de cache de cerca de 10%
|
Número de consultas simultâneas |
QC-OFF |
MySQL-QC (aumento de QPS comparado ao QC-OFF) |
Fast-QC (aumento de QPS comparado ao QC-OFF) |
|
1 |
5.004 |
4.727 (-5,54%) |
5.199 (3,90%) |
|
8 |
28.795 |
22.542 (-21,72%) |
28.578 (-0,75%) |
|
16 |
35.455 |
24.064 (-32,13%) |
35.682 (0,64%) |
|
32 |
34.526 |
21.330 (-38,22%) |
35.871 (3,90%) |
|
64 |
35.514 |
19.791 (-44,27%) |
36.051 (1,51%) |
|
128 |
35.983 |
19.519 (-45,75%) |
36.253 (0,75%) |
|
256 |
35.695 |
19.168 (-46,30%) |
36.337 (1,80%) |
|
512 |
35.182 |
18.420 (-47,64%) |
35.972 (2,25%) |
|
1.024 |
33.915 |
20.168 (-40,53%) |
34.546 (1,86%) |

O cache nativo do MySQL perde até 48% de QPS em condições de baixa taxa de acerto. O Fast Query Cache mantém-se dentro de 1–4% do QC-OFF, praticamente sem adicionar sobrecarga mesmo quando a maioria das consultas resulta em falha de cache.
Carga de trabalho mista de leitura e escrita
Usa o script oltp_read_write com atualizações frequentes de tabelas que invalidam constantemente as entradas em cache.
Tabela 4. QPS para consultas de leitura e escrita
|
Número de consultas simultâneas |
QC-OFF |
Fast-QC (aumento de QPS comparado ao QC-OFF) |
|
1 |
4.152 |
4.098 (-1,30%) |
|
8 |
21.359 |
21.195 (-0,77%) |
|
16 |
26.020 |
25.548 (-1,81%) |
|
32 |
27.595 |
26.996 (-2,17%) |
|
64 |
29.229 |
28.733 (-1,70%) |
|
128 |
29.265 |
28.828 (-1,49%) |
|
256 |
29.911 |
29.616 (-0,99%) |
|
512 |
29.148 |
28.816 (-1,14%) |
|
1.024 |
29.204 |
28.824 (-1,30%) |

O Fast Query Cache reduz o QPS em no máximo 2,17% em cargas de trabalho mistas de leitura e escrita. O mecanismo de invalidação incremental mantém baixa a sobrecarga de manutenção do cache mesmo sob escritas constantes.
Dimensionamento do cache
O query_cache_size afeta diretamente a taxa de acerto e o QPS. O benchmark a seguir mostra a relação entre o tamanho do cache e o desempenho em um conjunto de dados de 10 GB (100 tabelas, 400.000 registros por tabela, 20% de dados quentes, 64 threads simultâneas, innodb_buffer_pool_size = 6 GB):
Tabela 5. QPS com diferentes tamanhos de cache
|
query_cache_size (MB) |
QC-OFF |
Taxa de acerto do Fast-QC |
Fast-QC (aumento de QPS comparado ao QC-OFF) |
|
64 |
98.236 |
22% |
99.440 (1,23%) |
|
128 |
98.236 |
45% |
114.155 (16,21%) |
|
256 |
98.236 |
72% |
140.668 (43,19%) |
|
512 |
98.236 |
82% |
151.260 (53,98%) |
|
1.024 |
98.236 |
84% |
153.866 (56,63%) |
|
2.048 |
98.236 |
87% |
159.597 (62,46%) |
|
4.096 |
98.236 |
92% |
169.412 (72,45%) |
Principais observações deste teste:
O Fast Query Cache nunca reduz o QPS independentemente do tamanho do cache, mesmo com uma taxa de acerto de 22%.
Para consultas de chave primária, o Fast Query Cache supera o cache nativo do MySQL em qualquer taxa de acerto — em alguns casos, por mais de 90%.
Para consultas de intervalo e consultas com
ORDER BY, o Fast Query Cache oferece melhor desempenho que o cache nativo do MySQL quando a taxa de acerto está abaixo de 90%, além de economizar recursos significativos de CPU.
O tamanho real do conjunto de resultados para este teste foi de 2,5 GB. Dimensionar o cache para cobrir dados quentes (20% de 10 GB = 2 GB) exigiria aproximadamente 512 MB–1 GB de query_cache_size para atingir uma taxa de acerto superior a 80% neste cenário.
Alocar memória excessiva para o query_cache_size reduz a memória disponível para o InnoDB Buffer Pool, o que pode prejudicar o desempenho geral. Sempre reduza o innodb_buffer_pool_size proporcionalmente ao aumentar o query_cache_size.
Quando usar o Fast Query Cache
Use o Fast Query Cache quando
Sua carga de trabalho for intensiva em leitura com baixa frequência de escrita — por exemplo, páginas de detalhes de products de e-commerce ou consultas de relatórios.
Você quiser armazenar em cache tabelas específicas com altas proporções de leitura/escrita. Consulte a tabela
TABLE_STATISTICSpara identificar essas tabelas e use a palavra-chaveSQL_CACHEcomquery_cache_type = 2para armazenar em cache apenas essas consultas. Para detalhes sobre como consultarTABLE_STATISTICS, consulte Performance Insight.
Antes de ativar o Fast Query Cache globalmente, verifique a taxa de acerto do InnoDB Buffer Pool:
SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_reads';
SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_read_requests';
Taxa de acerto = 1 - (Innodb_buffer_pool_reads / Innodb_buffer_pool_read_requests)
Se a taxa de acerto do InnoDB Buffer Pool estiver abaixo de 80%, o buffer pool já está sob pressão de memória. Ativar o Fast Query Cache nesse estado — o que exige reduzir o innodb_buffer_pool_size — provavelmente prejudicará o desempenho. Aumente a memória da instância ou otimize as consultas antes de ativar o cache.
Evite o Fast Query Cache quando
Cargas de trabalho intensivas em escrita: Escritas frequentes causam invalidação constante do cache, adicionando sobrecarga com pouco benefício. Para sistemas de transação de alta frequência, mantenha
query_cache_type = 0.Requisitos de dados em tempo real: Resultados em cache podem ficar defasados em relação aos dados ativos. Para casos de uso como dados de mercado financeiro, onde leituras obsoletas são inaceitáveis, desative o cache ou use
SQL_NO_CACHEpor consulta.
Escolha o valor correto para query_cache_type
O query_cache_type suporta alterações no nível de sessão, permitindo ajustar o comportamento de cache por conexão sem modifique a configuração global:
SET SESSION query_cache_type = 1; -- enable for this session
SET SESSION query_cache_type = 0; -- disable for this session
|
Valor |
Comportamento |
Mais indicado para |
|
0 |
Desativa globalmente o Fast Query Cache |
Cargas de trabalho intensivas em escrita ou cenários com taxa de acerto muito baixa |
|
1 |
Ativa para todas as consultas elegíveis; use |
Cargas de trabalho intensivas em leitura com alterações infrequentes de dados |
|
2 |
Desativado globalmente; armazena em cache apenas consultas com |
Grandes conjuntos de dados, padrões de acesso imprevisíveis ou quando é necessário controle de cache no nível de tabela |