{"id":21018,"date":"2026-08-26T11:48:58","date_gmt":"2026-08-26T09:48:58","guid":{"rendered":"https:\/\/webhosting.de\/mysql-histograms-bessere-query-plaene-ohne-index-optimizer\/"},"modified":"2026-08-26T11:48:58","modified_gmt":"2026-08-26T09:48:58","slug":"histogramas-do-mysql-melhores-planos-de-consulta-sem-o-otimizador-de-indices","status":"publish","type":"post","link":"https:\/\/webhosting.de\/pt\/mysql-histograms-bessere-query-plaene-ohne-index-optimizer\/","title":{"rendered":"Histogramas do MySQL \u2013 Melhores planos de consulta sem \u00edndice"},"content":{"rendered":"<p><strong>Histogramas do MySQL<\/strong> fornecem ao otimizador dados reais sobre a distribui\u00e7\u00e3o, para que este possa estimar corretamente as seletividades e produzir planos de consulta mais r\u00e1pidos \u2013 muitas vezes, at\u00e9 sem necessidade de um \u00edndice adicional. Vou mostrar como configuro e verifico histogramas no MySQL 8+ com o comando ANALYZE TABLE e como os utilizo para tomar melhores decis\u00f5es em jun\u00e7\u00f5es, filtragens e varreduras.<\/p>\n\n<h2>Pontos centrais<\/h2>\n<p><strong>Foco curto<\/strong>: Os pontos-chave que se seguem mostram aquilo a que presto especial aten\u00e7\u00e3o quando utilizo histogramas.<\/p>\n<ul>\n  <li><strong>Seletividade<\/strong> Em vez de intui\u00e7\u00e3o: estimativas de cardinalidade mais realistas<\/li>\n  <li><strong>Sem \u00edndice<\/strong> mais r\u00e1pido: melhor sele\u00e7\u00e3o de planos em caso de distribui\u00e7\u00f5es assim\u00e9tricas<\/li>\n  <li><strong>tipos<\/strong> Compreender: Utilizar de forma seletiva o Singleton e o Equi-Height<\/li>\n  <li><strong>Baldes<\/strong> controlar: ponderar a dissolu\u00e7\u00e3o face aos custos dos metadados<\/li>\n  <li><strong>Cuidados<\/strong> Em destaque: atualizar, verificar e, se necess\u00e1rio, eliminar<\/li>\n<\/ul>\n\n<h2>Por que raz\u00e3o os histogramas sem \u00edndice t\u00eam efeito<\/h2>\n<p>Eu uso <strong>Histogramas<\/strong>, porque, caso contr\u00e1rio, o otimizador parte frequentemente do princ\u00edpio de que a distribui\u00e7\u00e3o \u00e9 uniforme e, por isso, escolhe planos inadequados. Um histograma representa a <strong>Distribui\u00e7\u00e3o de valores<\/strong> come\u00e7a a analisar uma coluna de forma aproximada, fornecendo assim estimativas realistas de seletividade para predicados como =, &gt;, BETWEEN, IN ou IS NULL. O otimizador decide ent\u00e3o se \u00e9 mais vantajoso um \u00abindex-range-scan\u00bb, um \u00abtable-scan\u00bb ou uma estrat\u00e9gia de jun\u00e7\u00e3o com \u00abnested loops\u00bb. Se, por exemplo, uma condi\u00e7\u00e3o abranger apenas 0,1 % das linhas, prefiro um acesso direcionado em vez de uma varredura ampla. Por outro lado, se um filtro abranger quase todas as linhas, dispenso os acessos a \u00edndices dispendiosos que n\u00e3o trazem vantagens, aumentando assim a <strong>Efici\u00eancia<\/strong> de cada plano.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/mysql-query-histograms-6793.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Tipos de histogramas no MySQL 8.0<\/h2>\n<p>Distingo duas <strong>tipos<\/strong>: Singleton e Equi-Height. Os histogramas Singleton agrupam valores \u00fanicos que ocorrem com frequ\u00eancia em intervalos separados \u2013 ideais para colunas com poucas categorias dominantes, como \u201eativo\u201c, \u201einativo\u201c ou \u201earquivado\u201c. Os histogramas Equi-Height dividem o intervalo de valores de forma a que cada intervalo contenha um n\u00famero semelhante de <strong>Linhas<\/strong> cont\u00e9m; isto \u00e9 adequado para distribui\u00e7\u00f5es cont\u00ednuas ou irregulares, como pre\u00e7os, carimbos de data\/hora ou intervalos de identifica\u00e7\u00e3o \u201ecom lacunas\u201c. Ambas as variantes fornecem ao otimizador taxas de correspond\u00eancia mais precisas para os filtros. Escolho sempre o tipo de acordo com as caracter\u00edsticas dos dados, e n\u00e3o com base em prefer\u00eancias pessoais.<\/p>\n\n<h2>No\u00e7\u00f5es t\u00e9cnicas b\u00e1sicas: controlar a sele\u00e7\u00e3o de tipos no MySQL<\/h2>\n<p>O MySQL determina a forma concreta <strong>Variante do histograma<\/strong> automaticamente com base na distribui\u00e7\u00e3o dos dados. Na pr\u00e1tica, isto significa que, se o n\u00famero de valores distintos (NDV) for suficientemente pequeno em rela\u00e7\u00e3o ao n\u00famero de intervalos, resulta efetivamente num histograma singleton; caso contr\u00e1rio, \u00e9 gerado um histograma de altura igual. Por isso, \u201eescolho\u201c o tipo <em>indireta<\/em>, definindo a coluna adequada e um n\u00famero adequado de intervalos. Para colunas com muito poucas categorias, mas fortemente dominantes, defino deliberadamente poucos buckets, de modo a obter uma precis\u00e3o do tipo \u00absingleton\u00bb para esses valores. No caso de dados cont\u00ednuos e bem dispersos, aumento os buckets gradualmente at\u00e9 que o EXPLAIN apresente o resultado desejado <strong>Seletividade<\/strong> reflete.<\/p>\n<p>Importante: os histogramas s\u00e3o <strong>em coluna \u00fanica<\/strong>. N\u00e3o \u00e9 poss\u00edvel representar diretamente as depend\u00eancias entre colunas (por exemplo, \u00abstatus\u00bb e \u00abcountry\u00bb). Nesses casos, \u00e9 \u00fatil aplicar um histograma \u00e0 coluna mais seletiva e definir a ordem das jun\u00e7\u00f5es em conformidade.<\/p>\n\n<h2>Escolher os baldes de forma correta<\/h2>\n<p>Por predefini\u00e7\u00e3o, o MySQL utiliza 100 <strong>Baldes<\/strong>, mas permite valores entre 1 e 1024 atrav\u00e9s da op\u00e7\u00e3o WITH N BUCKETS. Um maior n\u00famero de buckets aumenta a resolu\u00e7\u00e3o, mas tamb\u00e9m aumenta os metadados e o esfor\u00e7o de an\u00e1lise. Normalmente come\u00e7o de forma conservadora, avalio o impacto no EXPLAIN e vou aumentando gradualmente se o plano continuar a parecer inadequado. No caso de valores altamente concentrados (por exemplo, 90 % num \u00fanico estado), bastam frequentemente poucos buckets; no caso de pre\u00e7os ou carimbos de data\/hora bem dispersos, vale a pena utilizar mais buckets. O objetivo \u00e9 uma <strong>Granularidade<\/strong>, o que reduziu significativamente os erros de avalia\u00e7\u00e3o, sem aumentar desnecessariamente a carga administrativa.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/mysql_histogramm_meeting_8123.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Exemplo pr\u00e1tico: Fluxo de trabalho com ANALYZE TABLE<\/h2>\n<p>Sigo uma linha clara <strong>Fluxo de trabalho<\/strong>: Em primeiro lugar, identifico as colunas que aparecem frequentemente em condi\u00e7\u00f5es WHERE ou JOIN e que apresentam distribui\u00e7\u00f5es visivelmente assim\u00e9tricas. Em seguida, crio um histograma com ANALYZE TABLE tbl UPDATE HISTOGRAM ON col WITH N BUCKETS; e verifico-o atrav\u00e9s de INFORMATION_SCHEMA.COLUMN_STATISTICS. Ap\u00f3s transfer\u00eancias de dados, atualizo novamente com ANALYZE TABLE. Se uma estat\u00edstica n\u00e3o estiver correta, elimino-a com ANALYZE TABLE tbl DROP HISTOGRAM ON col;. Para avaliar o impacto no plano de execu\u00e7\u00e3o, consulto <a href=\"https:\/\/webhosting.de\/pt\/interpretar-consultas-mysql-explain-e-analyze-otimizacao-de-consultas\/\">Interpretar EXPLAIN ANALYZE<\/a> e estimativas semelhantes em compara\u00e7\u00e3o com os valores reais <strong>Linhas<\/strong> de.<\/p>\n\n<h2>Ordens concretas e controlo<\/h2>\n<p>Trabalho de forma reprodut\u00edvel, seguindo poucos passos claros, e verifico as estat\u00edsticas JSON geradas.<\/p>\n<pre><code>-- Criar histogramas em colunas individuais\nANALYZE TABLE orders UPDATE HISTOGRAM ON status WITH 32 BUCKETS;\nANALYZE TABLE orders UPDATE HISTOGRAM ON created_at WITH 128 BUCKETS;\n\n-- V\u00e1rias colunas numa \u00fanica execu\u00e7\u00e3o com o mesmo n\u00famero de buckets\nANALYZE TABLE orders UPDATE HISTOGRAM ON status, payment_method WITH 64 BUCKETS;\n\n-- Eliminar histogramas de forma seletiva\nANALYZE TABLE orders DROP HISTOGRAM ON status;\n<\/code><\/pre>\n<pre><code>-- An\u00e1lise visual das estat\u00edsticas\nSELECT\n  SCHEMA_NAME, TABLE_NAME, COLUMN_NAME,\n  JSON_PRETTY(HISTOGRAM) AS histogram\nFROM INFORMATION_SCHEMA.COLUMN_STATISTICS\nWHERE SCHEMA_NAME = DATABASE()\n  AND TABLE_NAME = 'orders'\n  AND COLUMN_NAME IN ('status','created_at');\n<\/code><\/pre>\n<p>Avalio o impacto diretamente com o comando EXPLAIN ANALYZE:<\/p>\n<pre><code>EXPLAIN ANALYZE\nSELECT *\nFROM orders\nWHERE status = 'canceled'\n  AND created_at &gt;= NOW() - INTERVAL 7 DAY;\n<\/code><\/pre>\n<p>A estimativa melhora? <strong>linhas<\/strong> Se for percet\u00edvel e o plano mudar, por exemplo, de \u00abFull Scan\u00bb para \u00abIndex-Range-Scan\u00bb, ou se alterar a ordem das jun\u00e7\u00f5es, a medida foi bem-sucedida. Se o desvio continuar a ser grande, aumentei ou reduzi o n\u00famero de buckets e comparo novamente.<\/p>\n\n<h2>Exemplo: Estado da encomenda e valores pouco frequentes<\/h2>\n<p>Numa tabela de encomendas, o estado \u201ecompleted\u201c \u00e9 frequentemente o mais comum, enquanto \u201epending\u201c \u00e9 relativamente frequente e \u201ecanceled\u201c \u00e9 muito raro; isto <strong>desequil\u00edbrio<\/strong> Sem um histograma, isto pode facilmente levar a seletividades incorretas. Se uma API consultar \u201ecanceled\u201c, o otimizador pode, por engano, optar por uma varredura completa da tabela, embora bastasse um acesso restrito ao \u00edndice. Com um histograma singleton, o MySQL reconhece que \u201ecanceled\u201c representa apenas uma percentagem \u00ednfima e opta por uma varredura de intervalo de \u00edndice ou otimiza a ordem das jun\u00e7\u00f5es. Desta forma, a lat\u00eancia diminui e n\u00e3o preciso de um \u00edndice adicional para cada <strong>Variante<\/strong> de um filtro. Nos pain\u00e9is com SLOs r\u00edgidos, esta corre\u00e7\u00e3o traz frequentemente vantagens percet\u00edveis em termos de resposta.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/mysql-histograms-server-room-2973.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>S\u00e9ries temporais e carimbos de data\/hora<\/h2>\n<p>No caso das s\u00e9ries temporais, h\u00e1 muitos <strong>Acessos<\/strong> com base em dados recentes; os intervalos de tempo mais antigos permanecem, na maioria das vezes, inativos. Um histograma de altura equidistante (Equi-Height) com base em `created_at` ou `updated_at` distingue os intervalos de tempo mais movimentados dos que s\u00e3o raramente utilizados. O otimizador avalia ent\u00e3o corretamente se uma varredura de intervalo (Range-Scan) faz sentido ou se uma varredura de tabela (Table-Scan) conduz mais rapidamente ao resultado pretendido. Especialmente no caso de filtros temporais parciais em tabelas de grande dimens\u00e3o, noto mudan\u00e7as significativas no plano de execu\u00e7\u00e3o e custos de E\/S mais baixos. Considero que a <strong>Estat\u00edsticas<\/strong> aqui \u00e9 atualizado com mais frequ\u00eancia, porque o foco muda de acordo com as atividades do dia-a-dia.<\/p>\n\n<h2>Parti\u00e7\u00f5es, tipos de dados e cola\u00e7\u00f5es<\/h2>\n<p>Nas tabelas particionadas, analiso a distribui\u00e7\u00e3o dos dados <strong>em todas as parti\u00e7\u00f5es<\/strong>. Diferen\u00e7as acentuadas (por exemplo, por meses) podem suavizar os histogramas globais. Caso algumas parti\u00e7\u00f5es sejam extremamente seletivas ou extremamente amplas, fa\u00e7o ainda um teste com filtros de \u00abpartition pruning\u00bb na cl\u00e1usula WHERE para verificar se a qualidade do plano de execu\u00e7\u00e3o continua a ser adequada. De um modo geral, procuro formular os filtros de forma a que o MySQL identifique as parti\u00e7\u00f5es numa fase inicial <strong>excluir<\/strong> pode.<\/p>\n<p>Os histogramas funcionam melhor com tipos de dados escalares e compar\u00e1veis (n\u00fameros, valores de data\/hora, VARCHAR\/CHAR com cola\u00e7\u00e3o adequada). No caso de <strong>Dados LOB\/JSON<\/strong> prefiro apostar em <em>Colunas geradas<\/em> com valores extra\u00eddos e tipificados e, se necess\u00e1rio, acompanhe-os com histogramas ou \u00edndices. No caso das cadeias de caracteres, a <strong>Colacionamento<\/strong> a l\u00f3gica de compara\u00e7\u00e3o; dependendo da ordena\u00e7\u00e3o, os valores podem coincidir (por exemplo, mai\u00fasculas\/min\u00fasculas). Mantenho a ordena\u00e7\u00e3o consistente com as consultas, para obter seletividades realistas.<\/p>\n\n<h2>Limites e erros<\/h2>\n<p>Os histogramas estimam, sobretudo, colunas individuais com <strong>Constantes<\/strong> Bem; representam as depend\u00eancias entre v\u00e1rias colunas apenas de forma limitada. No caso de colunas fortemente correlacionadas ou de par\u00e2metros din\u00e2micos (por exemplo, preenchidos pela aplica\u00e7\u00e3o), atingem os seus limites. Os campos booleanos ou as colunas com distribui\u00e7\u00e3o quase uniforme raramente beneficiam de estat\u00edsticas adicionais. Por outro lado, um n\u00famero excessivo de intervalos e uma manuten\u00e7\u00e3o excessiva podem, por sua vez, aumentar o tempo dedicado \u00e0 gest\u00e3o e \u00e0 an\u00e1lise. Por isso, utilizo os histogramas de forma seletiva e verifico regularmente a <strong>Efeito<\/strong> com base em exemplos reais.<\/p>\n\n<h2>Verifica\u00e7\u00e3o e atualiza\u00e7\u00e3o do Optimizer<\/h2>\n<p>Eu controlo o <strong>Utiliza\u00e7\u00e3o<\/strong> desde histogramas at\u00e9 ao comando ANALYZE TABLE e op\u00e7\u00f5es relevantes do otimizador, para que o planeador utilize as estat\u00edsticas de forma eficaz. Em sistemas com elevado volume de trabalho, planeio a atualiza\u00e7\u00e3o em intervalos de tempo mais calmos ou em lote, ap\u00f3s carregamentos de grande dimens\u00e3o. Antes e depois, comparo os resultados do EXPLAIN e do EXPLAIN ANALYZE para avaliar altera\u00e7\u00f5es nas sequ\u00eancias de jun\u00e7\u00f5es, etapas de filtragem e modelos de custos. Em caso de efeitos negativos, reajo imediatamente e reverto uma estat\u00edstica. Para um controlo mais aprofundado do <a href=\"https:\/\/webhosting.de\/pt\/mysql-optimizer-query-hosting-otimizacao-serverboost\/\">Op\u00e7\u00f5es do otimizador<\/a> tenho o cuidado de garantir que as depend\u00eancias com outras estat\u00edsticas n\u00e3o passem despercebidas e n\u00e3o resultem em erros <strong>Pressupostos<\/strong> produzir.<\/p>\n\n<h2>Monitoriza\u00e7\u00e3o, prote\u00e7\u00e3o contra regress\u00e3o e manual de procedimentos<\/h2>\n<p>Estou a construir um leve <strong>Manual de estrat\u00e9gias<\/strong> para o ambiente de produ\u00e7\u00e3o:<\/p>\n<ul>\n  <li>Definir valor de refer\u00eancia: antes de efetuar altera\u00e7\u00f5es, executar EXPLAIN ANALYZE e registar o tempo de execu\u00e7\u00e3o, o n\u00famero de \u201elinhas analisadas\u201c e o contador do handler.<\/li>\n  <li>Criar\/alterar histograma: com foco nas colunas de filtro, intervalos conservadores.<\/li>\n  <li>Medir imediatamente a seguir: plano, linhas estimadas vs. reais; um desvio com um fator &gt;10 \u00e9, para mim, um sinal de alerta.<\/li>\n  <li>Ajuste fino: aumentar\/diminuir os buckets; se necess\u00e1rio, ajustar a ordem dos filtros na consulta.<\/li>\n  <li>Manter um rollback pronto: executar DROP HISTOGRAM caso as lat\u00eancias aumentem.<\/li>\n  <li>Automatiza\u00e7\u00e3o: executar o comando ANALYZE durante as janelas de manuten\u00e7\u00e3o, ap\u00f3s carregamentos ETL ou grandes ondas de DML.<\/li>\n<\/ul>\n<p>Para a an\u00e1lise das causas, utilizo <strong>Rastreios do otimizador<\/strong> e EXPLAIN ANALYZE, para verificar se o planeador, com base nos histogramas, coloca a tabela seletiva correta \u201ena frente\u201c. Para testes A\/B, fixo a ordem das jun\u00e7\u00f5es (STRAIGHT_JOIN) a t\u00edtulo experimental ou for\u00e7o\/desativo \u00edndices espec\u00edficos, para avaliar o efeito das estat\u00edsticas de forma isolada.<\/p>\n<p>Do ponto de vista organizacional, uma breve <strong>Registo de altera\u00e7\u00f5es<\/strong> Por tabela: coluna, n\u00famero de intervalos, momento, valores medidos antes\/depois. Isto facilita corre\u00e7\u00f5es posteriores e evita intera\u00e7\u00f5es pouco claras.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/mysql_histogram_techoffice_4829.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Aspectos operacionais: bloqueios, custos, portabilidade<\/h2>\n<p>A fun\u00e7\u00e3o ANALYZE TABLE recebe uma <strong>Bloqueio de metadados<\/strong> na tabela, mas n\u00e3o bloqueia de forma permanente as opera\u00e7\u00f5es habituais de leitura\/grava\u00e7\u00e3o. Em tabelas muito grandes, prevejo tempo suficiente; a gera\u00e7\u00e3o do histograma funciona com amostras e est\u00e1 limitada pela mem\u00f3ria (palavra-chave: mem\u00f3ria interna para o c\u00e1lculo). O espa\u00e7o ocupado pelas pr\u00f3prias estat\u00edsticas permanece moderado: algumas dezenas a algumas centenas de kilobytes por coluna com 100\u2013256 buckets \u00e9 um valor de refer\u00eancia realista. No entanto, fa\u00e7o o c\u00e1lculo total, pois muitas colunas multiplicadas por muitas tabelas resultam em <strong>metadados vis\u00edveis<\/strong>.<\/p>\n<p>Em <strong>Dumps l\u00f3gicos<\/strong> (mysqldump) os histogramas n\u00e3o s\u00e3o inclu\u00eddos como dados; ap\u00f3s uma restaura\u00e7\u00e3o, recrio-os especificamente. Numa atualiza\u00e7\u00e3o no local (in-place upgrade), estes s\u00e3o mantidos. Do ponto de vista dos direitos, necessito de privil\u00e9gios suficientes para executar o comando ANALYZE TABLE nos respetivos objetos; em ambientes rigorosamente regulamentados, integro a manuten\u00e7\u00e3o em pipelines de manuten\u00e7\u00e3o.<\/p>\n\n<h2>Quando os histogramas n\u00e3o servem de nada<\/h2>\n<p>Vou poupar-me <strong>Histogramas<\/strong> em colunas que cont\u00eam muito poucos valores e que, de qualquer forma, s\u00e3o bem estimadas. Mesmo nos casos em que um bom \u00edndice j\u00e1 abrange conjuntos m\u00ednimos de resultados, um histograma raramente traz benef\u00edcios adicionais. As distribui\u00e7\u00f5es uniformes n\u00e3o requerem um n\u00edvel de detalhe excessivo. Em sistemas altamente din\u00e2micos e com grande volume de grava\u00e7\u00f5es, a atualiza\u00e7\u00e3o pode gerar uma carga desnecess\u00e1ria se for iniciada com demasiada frequ\u00eancia. Nessas situa\u00e7\u00f5es, recorro \u00e0 <strong>Energia<\/strong> prefiro as estrat\u00e9gias de indexa\u00e7\u00e3o, a conce\u00e7\u00e3o de consultas e o armazenamento em cache.<\/p>\n\n<h2>Ficha de refer\u00eancia em forma de tabela<\/h2>\n<p>Utilizo o seguinte <strong>Vis\u00e3o geral<\/strong> para decis\u00f5es r\u00e1pidas: que tipo de histograma \u00e9 o mais adequado, como definir os intervalos e quais s\u00e3o os custos envolvidos. A tabela serve como aux\u00edlio de mem\u00f3ria nas an\u00e1lises de consultas problem\u00e1ticas. Atualizo-a com base no que aprendi com o EXPLAIN ANALYZE e nas m\u00e9tricas de produ\u00e7\u00e3o. Ao faz\u00ea-lo, tenho em conta que as distribui\u00e7\u00f5es de dados mudam e que as hip\u00f3teses hist\u00f3ricas ficam desatualizadas. O que continua a ser decisivo \u00e9 a <strong>Qualidade do plano<\/strong> confirmar atrav\u00e9s de medi\u00e7\u00f5es reais.<\/p>\n<table>\n  <thead>\n    <tr>\n      <th>Aspeto<\/th>\n      <th>Recomenda\u00e7\u00e3o<\/th>\n      <th>Benef\u00edcio<\/th>\n      <th>compromisso<\/th>\n      <th>Exemplo<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>Tipo<\/td>\n      <td>Singleton no caso de poucos valores dominantes<\/td>\n      <td>Taxas de acerto precisas para categorias frequentes<\/td>\n      <td>Pouco \u00fatil em \u00e1reas cont\u00ednuas<\/td>\n      <td>estado_da_encomenda<\/td>\n    <\/tr>\n    <tr>\n      <td>Tipo<\/td>\n      <td>Equi-Height em dados cont\u00ednuos e distorcidos<\/td>\n      <td>Melhor estimativa ao longo do intervalo de valores<\/td>\n      <td>Mais metadados quando h\u00e1 muitos buckets<\/td>\n      <td>created_at, pre\u00e7o<\/td>\n    <\/tr>\n    <tr>\n      <td>Baldes<\/td>\n      <td>Come\u00e7ar por 100 e, depois, ajustar<\/td>\n      <td>Resolu\u00e7\u00e3o equilibrada<\/td>\n      <td>Maior carga de an\u00e1lise e armazenamento entre 512 e 1024<\/td>\n      <td>COM 100 BALDE<\/td>\n    <\/tr>\n    <tr>\n      <td>Cuidados<\/td>\n      <td>Ap\u00f3s altera\u00e7\u00f5es significativas nos dados, executar o comando ANALYZE<\/td>\n      <td>Seletividades atuais<\/td>\n      <td>Planear janelas de manuten\u00e7\u00e3o<\/td>\n      <td>ANALYZE TABLE \u2026 UPDATE HISTOGRAM<\/td>\n    <\/tr>\n    <tr>\n      <td>Controlo<\/td>\n      <td>Verificar atrav\u00e9s de COLUMN_STATISTICS<\/td>\n      <td>Transpar\u00eancia e auditoria<\/td>\n      <td>\u00c9 necess\u00e1ria a interpreta\u00e7\u00e3o de JSON<\/td>\n      <td>INFORMATION_SCHEMA.COLUMN_STATISTICS<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Integra\u00e7\u00e3o no panorama geral do tuning<\/h2>\n<p>Eu trato <strong>Histogramas<\/strong> como um elemento fundamental, a par dos \u00edndices, do desenho das consultas, do armazenamento em cache e dos par\u00e2metros de hardware. Muitas vezes, um bom histograma altera a ordem das jun\u00e7\u00f5es, reduz as opera\u00e7\u00f5es de E\/S e garante tempos de resposta constantes. No entanto, n\u00e3o substituo com isso estrat\u00e9gias de indexa\u00e7\u00e3o bem definidas nem um esquema eficiente. Quem analisar mais profundamente as decis\u00f5es de planeamento beneficia de <a href=\"https:\/\/webhosting.de\/pt\/planos-de-execucao-de-consultas-de-bases-de-dados-otimizacao-do-alojamento-informacoes-sobre-o-desempenho\/\">Compreender os planos de execu\u00e7\u00e3o<\/a> e compara modelos de custos com prazos reais. Verifico regularmente se o <strong>Cargas de trabalho<\/strong> se ainda se enquadram nas estat\u00edsticas ou se \u00e9 necess\u00e1rio fazer ajustes.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/mysql-queryplanung-8216.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Cen\u00e1rios avan\u00e7ados de jun\u00e7\u00e3o<\/h2>\n<p>Os histogramas revelam-se particularmente \u00fateis quando est\u00e3o envolvidas v\u00e1rias tabelas com filtros. Exemplo:<\/p>\n<pre><code>SELECT o.id, o.amount\nFROM users u\nJOIN orders o ON o.user_id = u.id\nWHERE u.country = 'DE'\n  AND o.status = 'canceled'\n  AND o.created_at &gt;= NOW() - INTERVAL 30 DAY;\n<\/code><\/pre>\n<p>Sem histogramas, o otimizador pode subestimar a seletividade de o.status=\u2019canceled\u2018 ou sobrestimar a percentagem de utilizadores alem\u00e3es. Com um histograma em <em>e pa\u00eds<\/em> e <em>sem estado<\/em> (se for o caso, tamb\u00e9m em <em>o.created_at<\/em>) o planeador geralmente percebe que a combina\u00e7\u00e3o \u00e9 extremamente seletiva. Na pr\u00e1tica, vejo ent\u00e3o que o MySQL determina primeiro o subconjunto mais pequeno (por exemplo, atrav\u00e9s de um \u00edndice em users(country) ou orders(status, created_at)) e s\u00f3 depois executa a jun\u00e7\u00e3o \u2013 em vez de analisar a tabela grande. Isto poupa E\/S, mem\u00f3ria tamp\u00e3o e CPU e estabiliza a lat\u00eancia, mesmo sob carga.<\/p>\n<p>Porque os histogramas apenas <strong>em coluna \u00fanica<\/strong> as estrat\u00e9gias de \u00edndice continuam a ser importantes: um \u00edndice composto com base em (status, created_at) pode acelerar ainda mais a varredura de intervalo. O histograma garante, neste caso, sobretudo que o otimizador utilize este <em>Estrat\u00e9gia<\/em> considera, de facto, que \u00e9 barato.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/mysql_histogram_desk_4721.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Resumo para a pr\u00e1tica<\/h2>\n<p>Eu fixo <strong>MySQL<\/strong>-Utilizo histogramas quando o otimizador se engana com as estat\u00edsticas padr\u00e3o e as distribui\u00e7\u00f5es assim\u00e9tricas geram planos errados. Com o ANALYZE TABLE, crio, atualizo e elimino estat\u00edsticas de forma seletiva nas colunas que predominam nos filtros e nas jun\u00e7\u00f5es. A escolha entre \u00abSingleton\u00bb e \u00abEqui-Height\u00bb \u00e9 feita com base nos dados, e o n\u00famero de buckets \u00e9 calibrado com medi\u00e7\u00f5es. Atrav\u00e9s do comando EXPLAIN ANALYZE, verifico se as sequ\u00eancias de jun\u00e7\u00f5es, as posi\u00e7\u00f5es dos filtros e as varreduras se alteram conforme desejado. Assim, consigo, com poucos <strong>Despesas gerais<\/strong> consultas visivelmente mais r\u00e1pidas \u2013 muitas vezes sem necessidade de \u00edndices adicionais.<\/p>","protected":false},"excerpt":{"rendered":"<p>Descubra como os histogramas do MySQL fornecem estat\u00edsticas precisas ao otimizador, permitem melhores planos de consulta e melhoram significativamente o seu ajuste de SQL sem a necessidade de \u00edndices adicionais.<\/p>","protected":false},"author":1,"featured_media":21011,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[781],"tags":[],"class_list":["post-21018","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-datenbanken-administration-anleitungen"],"acf":[],"_wp_attached_file":null,"_wp_attachment_metadata":null,"litespeed-optimize-size":null,"litespeed-optimize-set":null,"_elementor_source_image_hash":null,"_wp_attachment_image_alt":null,"stockpack_author_name":null,"stockpack_author_url":null,"stockpack_provider":null,"stockpack_image_url":null,"stockpack_license":null,"stockpack_license_url":null,"stockpack_modification":null,"color":null,"original_id":null,"original_url":null,"original_link":null,"unsplash_location":null,"unsplash_sponsor":null,"unsplash_exif":null,"unsplash_attachment_metadata":null,"_elementor_is_screenshot":null,"surfer_file_name":null,"surfer_file_original_url":null,"envato_tk_source_kit":null,"envato_tk_source_index":null,"envato_tk_manifest":null,"envato_tk_folder_name":null,"envato_tk_builder":null,"envato_elements_download_event":null,"_menu_item_type":null,"_menu_item_menu_item_parent":null,"_menu_item_object_id":null,"_menu_item_object":null,"_menu_item_target":null,"_menu_item_classes":null,"_menu_item_xfn":null,"_menu_item_url":null,"_trp_menu_languages":null,"rank_math_primary_category":null,"rank_math_title":null,"inline_featured_image":null,"_yoast_wpseo_primary_category":null,"rank_math_schema_blogposting":null,"rank_math_schema_videoobject":null,"_oembed_049c719bc4a9f89deaead66a7da9fddc":null,"_oembed_time_049c719bc4a9f89deaead66a7da9fddc":null,"_yoast_wpseo_focuskw":null,"_yoast_wpseo_linkdex":null,"_oembed_27e3473bf8bec795fbeb3a9d38489348":null,"_oembed_c3b0f6959478faf92a1f343d8f96b19e":null,"_trp_translated_slug_en_us":null,"_wp_desired_post_slug":null,"_yoast_wpseo_title":null,"tldname":null,"tldpreis":null,"tldrubrik":null,"tldpolicylink":null,"tldsize":null,"tldregistrierungsdauer":null,"tldtransfer":null,"tldwhoisprivacy":null,"tldregistrarchange":null,"tldregistrantchange":null,"tldwhoisupdate":null,"tldnameserverupdate":null,"tlddeletesofort":null,"tlddeleteexpire":null,"tldumlaute":null,"tldrestore":null,"tldsubcategory":null,"tldbildname":null,"tldbildurl":null,"tldclean":null,"tldcategory":null,"tldpolicy":null,"tldbesonderheiten":null,"tld_bedeutung":null,"_oembed_d167040d816d8f94c072940c8009f5f8":null,"_oembed_b0a0fa59ef14f8870da2c63f2027d064":null,"_oembed_4792fa4dfb2a8f09ab950a73b7f313ba":null,"_oembed_33ceb1fe54a8ab775d9410abf699878d":null,"_oembed_fd7014d14d919b45ec004937c0db9335":null,"_oembed_21a029d076783ec3e8042698c351bd7e":null,"_oembed_be5ea8a0c7b18e658f08cc571a909452":null,"_oembed_a9ca7a298b19f9b48ec5914e010294d2":null,"_oembed_f8db6b27d08a2bb1f920e7647808899a":null,"_oembed_168ebde5096e77d8a89326519af9e022":null,"_oembed_cdb76f1b345b42743edfe25481b6f98f":null,"_oembed_87b0613611ae54e86e8864265404b0a1":null,"_oembed_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_oembed_time_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_tldname":null,"_tldclean":null,"_tldpreis":null,"_tldcategory":null,"_tldsubcategory":null,"_tldpolicy":null,"_tldpolicylink":null,"_tldsize":null,"_tldregistrierungsdauer":null,"_tldtransfer":null,"_tldwhoisprivacy":null,"_tldregistrarchange":null,"_tldregistrantchange":null,"_tldwhoisupdate":null,"_tldnameserverupdate":null,"_tlddeletesofort":null,"_tlddeleteexpire":null,"_tldumlaute":null,"_tldrestore":null,"_tldbildname":null,"_tldbildurl":null,"_tld_bedeutung":null,"_tldbesonderheiten":null,"_oembed_ad96e4112edb9f8ffa35731d4098bc6b":null,"_oembed_8357e2b8a2575c74ed5978f262a10126":null,"_oembed_3d5fea5103dd0d22ec5d6a33eff7f863":null,"_eael_widget_elements":null,"_oembed_0d8a206f09633e3d62b95a15a4dd0487":null,"_oembed_time_0d8a206f09633e3d62b95a15a4dd0487":null,"_aioseo_description":null,"_eb_attr":null,"_eb_data_table":null,"_oembed_819a879e7da16dd629cfd15a97334c8a":null,"_oembed_time_819a879e7da16dd629cfd15a97334c8a":null,"_acf_changed":null,"_wpcode_auto_insert":null,"_edit_last":null,"_edit_lock":null,"_oembed_e7b913c6c84084ed9702cb4feb012ddd":null,"_oembed_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_time_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_03514b67990db061d7c4672de26dc514":null,"_oembed_time_03514b67990db061d7c4672de26dc514":null,"rank_math_news_sitemap_robots":null,"rank_math_robots":null,"_eael_post_view_count":"105","_trp_automatically_translated_slug_ru_ru":null,"_trp_automatically_translated_slug_et":null,"_trp_automatically_translated_slug_lv":null,"_trp_automatically_translated_slug_fr_fr":null,"_trp_automatically_translated_slug_en_us":null,"_wp_old_slug":null,"_trp_automatically_translated_slug_da_dk":null,"_trp_automatically_translated_slug_pl_pl":null,"_trp_automatically_translated_slug_es_es":null,"_trp_automatically_translated_slug_hu_hu":null,"_trp_automatically_translated_slug_fi":null,"_trp_automatically_translated_slug_ja":null,"_trp_automatically_translated_slug_lt_lt":null,"_elementor_edit_mode":null,"_elementor_template_type":null,"_elementor_version":null,"_elementor_pro_version":null,"_wp_page_template":null,"_elementor_page_settings":null,"_elementor_data":null,"_elementor_css":null,"_elementor_conditions":null,"_happyaddons_elements_cache":null,"_oembed_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_time_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_time_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_59808117857ddf57e478a31d79f76e4d":null,"_oembed_time_59808117857ddf57e478a31d79f76e4d":null,"_oembed_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_time_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_81002f7ee3604f645db4ebcfd1912acf":null,"_oembed_time_81002f7ee3604f645db4ebcfd1912acf":null,"_elementor_screenshot":null,"_oembed_7ea3429961cf98fa85da9747683af827":null,"_oembed_time_7ea3429961cf98fa85da9747683af827":null,"_elementor_controls_usage":null,"_elementor_page_assets":[],"_elementor_screenshot_failed":null,"theplus_transient_widgets":null,"_eael_custom_js":null,"_wp_old_date":null,"_trp_automatically_translated_slug_it_it":null,"_trp_automatically_translated_slug_pt_pt":null,"_trp_automatically_translated_slug_zh_cn":null,"_trp_automatically_translated_slug_nl_nl":null,"_trp_automatically_translated_slug_pt_br":null,"_trp_automatically_translated_slug_sv_se":null,"rank_math_analytic_object_id":null,"rank_math_internal_links_processed":"1","_trp_automatically_translated_slug_ro_ro":null,"_trp_automatically_translated_slug_sk_sk":null,"_trp_automatically_translated_slug_bg_bg":null,"_trp_automatically_translated_slug_sl_si":null,"litespeed_vpi_list":null,"litespeed_vpi_list_mobile":null,"rank_math_seo_score":null,"rank_math_contentai_score":null,"ilj_limitincominglinks":null,"ilj_maxincominglinks":null,"ilj_limitoutgoinglinks":null,"ilj_maxoutgoinglinks":null,"ilj_limitlinksperparagraph":null,"ilj_linksperparagraph":null,"ilj_blacklistdefinition":null,"ilj_linkdefinition":null,"_eb_reusable_block_ids":null,"rank_math_focus_keyword":"MySQL Histograms","rank_math_og_content_image":null,"_yoast_wpseo_metadesc":null,"_yoast_wpseo_content_score":null,"_yoast_wpseo_focuskeywords":null,"_yoast_wpseo_keywordsynonyms":null,"_yoast_wpseo_estimated-reading-time-minutes":null,"rank_math_description":null,"surfer_last_post_update":null,"surfer_last_post_update_direction":null,"surfer_keywords":null,"surfer_location":null,"surfer_draft_id":null,"surfer_permalink_hash":null,"surfer_scrape_ready":null,"_thumbnail_id":"21011","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts\/21018","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/comments?post=21018"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts\/21018\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/media\/21011"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/media?parent=21018"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/categories?post=21018"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/tags?post=21018"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}