Pular para o conteúdo principal
Este artigo descreve como a materialização tardia funciona e como ela se encaixa no conjunto mais amplo de otimizações de E/S do ClickHouse. Ele apresenta um exemplo real que demonstra como a materialização tardia melhora o desempenho das consultas.
Disponível a partir da versão 25.4A materialização tardia foi introduzida na versão 25.4 do ClickHouse e é ativada por padrão.

​
Visão geral

Ao longo dos anos, o ClickHouse introduziu uma série de otimizações em camadas para reduzir agressivamente o I/O. Essas técnicas formam a base da sua velocidade e eficiência: Embora as otimizações de I/O mencionadas acima possam reduzir significativamente o volume de dados lidos, elas ainda pressupõem que todas as colunas das linhas que passam pela cláusula WHERE precisam ser carregadas antes da execução de operações como ordenação, aggregation ou LIMIT. Mas e se algumas colunas só forem necessárias mais adiante, ou se alguns dados, apesar de passarem pela cláusula WHERE, nunca chegarem a ser necessários? É aí que entra a materialização tardia. Trata-se de um aprimoramento ortogonal que completa a pilha de otimizações de I/O:
  • A indexação, em conjunto com PREWHERE, garante que apenas as linhas que correspondem aos filtros de coluna na cláusula WHERE sejam processadas.
  • A materialização tardia se baseia nisso ao adiar as leituras de colunas até que elas sejam realmente necessárias no plano de execução da consulta. Mesmo após a filtragem, apenas as colunas necessárias para a próxima operação - como ordenação - são carregadas imediatamente. As demais são adiadas e, devido ao LIMIT, muitas vezes são lidas apenas parcialmente, apenas o suficiente para produzir o resultado final. Isso torna a materialização tardia especialmente poderosa para consultas Top N, em que o resultado final pode exigir apenas algumas linhas de determinadas colunas, muitas vezes grandes.

​
Um exemplo prático

Recomendamos fortemente o post do blog “ClickHouse gets lazier (and faster): Introducing lazy materialization” para um aprofundamento em materialização tardia. O exemplo abaixo foi extraído do post mencionado anteriormente e reproduzido aqui para demonstrar como uma consulta do ClickHouse pode passar de 219 segundos para apenas 139 milissegundos (uma aceleração de 1576×) com materialização tardia. Para se beneficiar de indexação e de PREWHERE, uma consulta precisa de filtros: em colunas de chave primária para indexação e em quaisquer colunas para PREWHERE. materialização tardia se aplica de forma natural sobre essas otimizações, mas, diferentemente das outras otimizações mencionadas anteriormente, também pode acelerar consultas sem nenhum filtro de coluna. Considere a consulta de exemplo a seguir, que encontra avaliações da Amazon com o maior número de votos úteis, independentemente de data, produto, nota ou status de verificação, e retorna as 3 principais com seu título, subtítulo e texto completo. Primeiro, execute a consulta (com caches frios do filesystem) com materialização tardia desativada (usando query_plan_optimize_lazy_materialization):
Query
Response
Em seguida, a consulta é executada novamente (mais uma vez com o cache frio do sistema de arquivos), mas desta vez com a materialização tardia ativada:
Query
Em geral, você não precisa definir explicitamente query_plan_optimize_lazy_materialization = true para aproveitar os benefícios de materialização tardia. Ela vem habilitada por padrão.
Response
Considere a diferença de desempenho com a materialização tardia desativada e ativada:

​
Como confirmar a materialização tardia no plano de execução da consulta

Você pode verificar o uso da materialização tardia na consulta anterior inspecionando o plano lógico de execução da consulta com a cláusula EXPLAIN:
Você pode ler o plano do operador de baixo para cima e observar que o ClickHouse adia a leitura das três colunas grandes do tipo String até depois da ordenação e da aplicação do limite.
Última modificação em 12 de junho de 2026