{"id":2487,"date":"2026-07-22T15:13:23","date_gmt":"2026-07-22T15:13:23","guid":{"rendered":"https:\/\/www.tiagoneves.net\/blog\/?p=2487"},"modified":"2026-07-22T15:14:40","modified_gmt":"2026-07-22T15:14:40","slug":"estatisticas-no-sql-server-por-que-seus-planos-de-execucao-comecam-aqui","status":"publish","type":"post","link":"https:\/\/www.tiagoneves.net\/blog\/estatisticas-no-sql-server-por-que-seus-planos-de-execucao-comecam-aqui\/","title":{"rendered":"Estat\u00edsticas no SQL Server: por que seus planos de execu\u00e7\u00e3o come\u00e7am aqui"},"content":{"rendered":"\n

Post 01 de 03 da s\u00e9rie Estat\u00edsticas: SQL Server \u00d7 PostgreSQL<\/strong><\/em><\/p>\n\n\n\n

O sintoma que ningu\u00e9m questiona<\/mark><\/h3>\n\n\n\n

Toda madrugada, \u00e0s 02h00, uma rotina de UPDATE STATISTICS entra em execu\u00e7\u00e3o em um ambiente que administro. A tabela principal tem cerca de 4 bilh\u00f5es de linhas e 2 TB<\/strong>, particionada por per\u00edodo. A rotina varria, a cada execu\u00e7\u00e3o, 2,8 bilh\u00f5es de linhas<\/strong> para atualizar estat\u00edsticas de dados que em sua esmagadora maioria n\u00e3o mudaram nada desde a noite anterior.<\/p>\n\n\n\n

Voce pode se perguntar o Por qu\u00ea? porque em uma tabela particionada por data, a escrita acontece quase toda na \u00faltima parti\u00e7\u00e3o<\/strong>. As parti\u00e7\u00f5es hist\u00f3ricas s\u00e3o, na pr\u00e1tica, read-only. Mas a rotina n\u00e3o sabia disso, ela atualizava a estat\u00edstica da tabela inteira, toda noite, consumindo horas de janela de manuten\u00e7\u00e3o, I\/O e CPU para reler bilh\u00f5es de linhas congeladas.<\/p>\n\n\n\n

Esse \u00e9 o retrato de muitos ambientes que avalio a rotina de estat\u00edsticas foi herdada, roda porque “sempre rodou assim, desde antes de eu entrar na empresa”, e ningu\u00e9m parou para perguntar o que exatamente ela est\u00e1 atualizando e se precisava<\/strong>.<\/p>\n\n\n\n

Para responder essa pergunta, precisamos voltar um passo e entender o que \u00e9, afinal, uma estat\u00edstica?<\/p>\n\n\n\n

O que \u00e9 uma estat\u00edstica (de verdade)<\/mark><\/h3>\n\n\n\n

Estat\u00edstica n\u00e3o \u00e9 um n\u00famero m\u00e1gico. Segundo a documenta\u00e7\u00e3o oficial da Microsoft<\/a>, estat\u00edsticas de otimiza\u00e7\u00e3o de consulta s\u00e3o BLOBs (binary large objects)<\/strong> que armazenam informa\u00e7\u00e3o sobre a distribui\u00e7\u00e3o de valores em uma ou mais colunas de uma tabela ou view indexada. O otimizador usa esses objetos para estimar a cardinalidade<\/strong>, o n\u00famero de linhas, de cada etapa da consulta, e \u00e9 essa estimativa que decide, por exemplo, entre um Index Seek e um Index Scan, entre um Nested Loops e um Hash Match.<\/p>\n\n\n\n

Kalen Delaney e coautores, no livroe Microsoft SQL Server Internals<\/em> (Microsoft Press), resumem bem a ess\u00eancia do problema: o otimizador \u00e9 baseado em custo<\/strong>, e o custo \u00e9 calculado sobre estimativas,<\/strong> ele nunca olha os dados reais no momento da compila\u00e7\u00e3o, apenas os valores estat\u00edstico que existe deles. Se os valores est\u00e3o velhos ou mal amostrado, o otimizador toma uma decis\u00e3o racional sobre uma premissa errada.<\/p>\n\n\n\n

Fisicamente, esse objeto \u00e9 composto por tr\u00eas partes:<\/p>\n\n\n\n

1. O histograma.<\/strong> Uma representa\u00e7\u00e3o da distribui\u00e7\u00e3o de valores da coluna l\u00edder<\/strong> da estat\u00edstica, com no m\u00e1ximo 200 steps<\/strong>. Cada step guarda um valor de fronteira (RANGE_HI_KEY<\/code>), quantas linhas t\u00eam exatamente aquele valor (EQ_ROWS<\/code>), quantas caem dentro do intervalo (RANGE_ROWS<\/code>) e quantos valores distintos existem (DISTINCT_RANGE_ROWS<\/code>).<\/p>\n\n\n\n

Pare um segundo nesse n\u00famero: 200 steps<\/strong>. N\u00e3o importa se a tabela tem 10 mil ou 4 bilh\u00f5es de linhas o otimizador enxerga a distribui\u00e7\u00e3o dos seus dados resumida em, no m\u00e1ximo, 200 faixas. Em tabelas gigantes, cada step pode representar milh\u00f5es de linhas, e valores “escondidos” dentro de um range podem ter estimativas bem distantes da realidade.<\/p>\n\n\n\n

Um detalhe de internals que vale conhecer, o histograma n\u00e3o nasce de um simples “divide em 200 peda\u00e7os”. A documenta\u00e7\u00e3o da Microsoft descreve a constru\u00e7\u00e3o em tr\u00eas etapas<\/strong>, sobre o conjunto ordenado de valores da coluna:<\/p>\n\n\n\n

    \n
  1. Inicializa\u00e7\u00e3o:<\/strong> os primeiros valores da sequ\u00eancia ordenada s\u00e3o processados e at\u00e9 200 valores de RANGE_HI_KEY<\/code> s\u00e3o coletados;<\/li>\n\n\n\n
  2. Scan com merge de buckets:<\/strong> cada valor seguinte \u00e9 adicionado ao \u00faltimo range ou vira um novo range no fim e, quando um novo range nasce, um par de ranges vizinhos \u00e9 colapsado<\/strong> em um s\u00f3, escolhido de forma a minimizar a perda de informa\u00e7\u00e3o. \u00c9 o chamado algoritmo de maximum difference<\/em>, minimizar o n\u00famero de steps maximizando a diferen\u00e7a entre os valores de fronteira;<\/li>\n\n\n\n
  3. Consolida\u00e7\u00e3o:<\/strong> ranges adicionais podem ser colapsados se isso n\u00e3o perder informa\u00e7\u00e3o relevante, por isso um histograma pode terminar com menos<\/em> de 200 steps mesmo em colunas com milhares de valores distintos.<\/li>\n<\/ol>\n\n\n\n

    Importante:<\/strong><\/mark> o histograma \u00e9 constru\u00eddo somente sobre a primeira coluna<\/strong> (a coluna principal) do conjunto de chaves da estat\u00edstica. As demais colunas de uma estat\u00edstica multi-coluna s\u00f3 contribuem para o density vector, o que explica por que a ordem das colunas em \u00edndices e estat\u00edsticas importa tanto para a qualidade das estimativas.<\/p>\n\n\n\n

    2. O density vector:<\/strong> A medida de seletividade m\u00e9dia das colunas, calculada como 1 \/ n\u00famero de valores distintos<\/strong>, quanto menor a density, mais seletiva a coluna (pense numa coluna de CPF, onde cada valor identifica uma \u00fanica pessoa, versus uma coluna de cidade, onde o mesmo valor se repete milhares de vezes). \u00c9 ele que o otimizador usa quando n\u00e3o consegue usar o histograma, por exemplo, em predicados com vari\u00e1veis locais ou em colunas secund\u00e1rias de estat\u00edsticas multi-coluna.<\/p>\n\n\n\n

    E h\u00e1 uma sutileza que derruba muita gente: o density vector guarda um density para cada prefixo<\/strong> das colunas da estat\u00edstica. Uma estat\u00edstica em (CustomerId, ItemId, Price)<\/code> tem densities para (CustomerId)<\/code>, (CustomerId, ItemId)<\/code> e (CustomerId, ItemId, Price)<\/code>, mas n\u00e3o<\/strong> para (CustomerId, Price)<\/code>. Se a sua consulta filtra por CustomerId<\/code> e Price<\/code> pulando a coluna do meio, aquela correla\u00e7\u00e3o simplesmente n\u00e3o existe para o otimizador.<\/p>\n\n\n\n

    E o que acontece, ent\u00e3o, quando a consulta filtra s\u00f3 por CustomerId<\/code> e Price<\/code>? O otimizador n\u00e3o desiste<\/strong>, ele estima cada predicado isoladamente (o CustomerId<\/code> pelo histograma dessa estat\u00edstica, j\u00e1 que \u00e9 a coluna l\u00edder; o Price<\/code> por alguma outra estat\u00edstica que tenha Price<\/code> como l\u00edder, tipicamente uma _WA_Sys_<\/code> auto-criada) e depois combina as duas seletividades por uma f\u00f3rmula<\/strong>. E \u00e9 aqui que a vers\u00e3o do Cardinality Estimator muda tudo:<\/p>\n\n\n\n