{"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":"istogrammi-mysql-piani-di-query-migliori-senza-lottimizzatore-di-indici","status":"publish","type":"post","link":"https:\/\/webhosting.de\/it\/mysql-histograms-bessere-query-plaene-ohne-index-optimizer\/","title":{"rendered":"Istogrammi MySQL \u2013 Piani di query ottimizzati senza indici"},"content":{"rendered":"<p><strong>Istogrammi MySQL<\/strong> forniscono all\u2019ottimizzatore dati di distribuzione reali, consentendogli di stimare correttamente le selettivit\u00e0 e di generare piani di query pi\u00f9 veloci \u2013 spesso persino senza indici aggiuntivi. Vi mostrer\u00f2 come impostare e controllare gli istogrammi in MySQL 8+ con ANALYZE TABLE e come utilizzarli per prendere decisioni migliori in caso di join, filtri e scansioni.<\/p>\n\n<h2>Punti centrali<\/h2>\n<p><strong>In breve<\/strong>: I seguenti punti chiave illustrano gli aspetti a cui presto particolare attenzione quando utilizzo gli istogrammi.<\/p>\n<ul>\n  <li><strong>Selettivit\u00e0<\/strong> Invece di affidarsi all\u2019istinto: stime di cardinalit\u00e0 pi\u00f9 realistiche<\/li>\n  <li><strong>Senza indice<\/strong> pi\u00f9 veloce: scelta migliore del piano in caso di distribuzioni asimmetriche<\/li>\n  <li><strong>Tipi<\/strong> Comprendere: l'uso mirato di Singleton e Equi-Height<\/li>\n  <li><strong>Secchielli<\/strong> gestire: valutare la soppressione rispetto ai costi dei metadati<\/li>\n  <li><strong>Cura<\/strong> In primo piano: aggiornare, verificare, eliminare se necessario<\/li>\n<\/ul>\n\n<h2>Perch\u00e9 gli istogrammi senza indice sono efficaci<\/h2>\n<p>Uso <strong>Istogrammi<\/strong>, perch\u00e9 altrimenti l\u2019ottimizzatore spesso ipotizza una distribuzione uniforme e di conseguenza sceglie piani non ottimali. Un istogramma rappresenta la <strong>Distribuzione dei valori<\/strong> partendo da un intervallo approssimativo di una colonna e fornendo cos\u00ec stime realistiche della selettivit\u00e0 per predicati come =, &gt;, BETWEEN, IN o IS NULL. L\u2019ottimizzatore decide quindi se sia pi\u00f9 vantaggiosa una scansione di intervallo dell\u2019indice, una scansione della tabella o una strategia di join con Nested Loops. Se, ad esempio, una condizione interessa solo lo 0,1% delle righe, preferisco un accesso mirato piuttosto che una scansione estesa. Se invece un filtro copre quasi tutte le righe, rinuncio a costosi accessi agli indici che non apportano alcun vantaggio, aumentando cos\u00ec la <strong>Efficienza<\/strong> di ogni piano.<\/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>Tipi di istogramma in MySQL 8.0<\/h2>\n<p>Distinguo due <strong>Tipi<\/strong>: Singleton ed Equi-Height. Gli istogrammi Singleton raggruppano i valori singoli pi\u00f9 frequenti in intervalli separati \u2013 ideali per colonne con poche categorie dominanti come \u201eattivo\u201c, \u201einattivo\u201c o \u201earchiviato\u201c. Gli istogrammi Equi-Height suddividono l\u2019intervallo di valori in modo tale che ogni intervallo contenga un numero simile di <strong>Linee<\/strong> ; questa opzione \u00e8 adatta a distribuzioni continue o distorte, come prezzi, timestamp o intervalli di ID \u201econ lacune\u201c. Entrambe le varianti forniscono all\u2019ottimizzatore percentuali di corrispondenza pi\u00f9 precise per i filtri. Scelgo sempre il tipo in base alle caratteristiche dei dati, non in base alle mie preferenze personali.<\/p>\n\n<h2>Nozioni tecniche di base: gestire la scelta del tipo di dati in MySQL<\/h2>\n<p>MySQL determina la specifica <strong>Variante dell'istogramma<\/strong> automaticamente in base alla distribuzione dei dati. In pratica, ci\u00f2 significa che se il numero di valori distinti (NDV) \u00e8 sufficientemente basso rispetto al numero di intervalli, si ottiene di fatto un istogramma singleton; in caso contrario, viene generato un istogramma equi-height. Pertanto, \u201escelgo\u201c il tipo <em>indiretto<\/em>, specificando la colonna appropriata e un numero adeguato di bucket. Per le colonne con pochissime categorie, ma fortemente dominanti, imposto volutamente pochi bucket per ottenere una precisione simile a quella dei singleton per questi valori. In caso di dati continui e finemente distribuiti, aumento gradualmente il numero di bucket fino a quando EXPLAIN non restituisce il risultato desiderato. <strong>Selettivit\u00e0<\/strong> riflette.<\/p>\n<p>Importante: gli istogrammi sono <strong>a colonna singola<\/strong>. Non \u00e8 possibile rappresentare direttamente le dipendenze tra colonne (ad esempio, \"status\" e \"country\"). In questi casi, \u00e8 utile applicare un istogramma alla colonna pi\u00f9 selettiva e impostare di conseguenza l'ordine dei join.<\/p>\n\n<h2>Scegliere i secchi in modo corretto<\/h2>\n<p>MySQL utilizza 100 per impostazione predefinita <strong>Secchielli<\/strong>, ma consente di impostare valori compresi tra 1 e 1024 tramite WITH N BUCKETS. Un numero maggiore di bucket aumenta la risoluzione, ma comporta un aumento dei metadati e del carico di analisi. Di solito parto con un valore prudente, valuto l\u2019effetto su EXPLAIN e lo aumento gradualmente se il piano continua a sembrare inadeguato. In presenza di valori fortemente concentrati (ad es. 90 % in uno stato) spesso bastano pochi bucket; in caso di prezzi o timestamp distribuiti in modo pi\u00f9 uniforme, conviene utilizzare pi\u00f9 bucket. L\u2019obiettivo \u00e8 un\u2019impostazione ragionevole <strong>Granularit\u00e0<\/strong>, riducendo sensibilmente gli errori di valutazione senza aumentare inutilmente l'onere amministrativo.<\/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>Esempio pratico: flusso di lavoro con ANALYZE TABLE<\/h2>\n<p>Seguo una linea chiara <strong>Flusso di lavoro<\/strong>: Per prima cosa identifico le colonne che compaiono spesso nelle condizioni WHERE o JOIN e che presentano distribuzioni palesemente asimmetriche. Quindi genero un istogramma con ANALYZE TABLE tbl UPDATE HISTOGRAM ON col WITH N BUCKETS; e lo verifico tramite INFORMATION_SCHEMA.COLUMN_STATISTICS. Dopo eventuali spostamenti dei dati, aggiorno nuovamente con ANALYZE TABLE. Se una statistica non \u00e8 corretta, la rimuovo con ANALYZE TABLE tbl DROP HISTOGRAM ON col;. Per valutare l\u2019efficacia del piano di esecuzione, leggo <a href=\"https:\/\/webhosting.de\/it\/mysql-explain-analyze-interpretare-le-query-ottimizzazione-delle-query\/\">Interpretazione di EXPLAIN ANALYZE<\/a> e le stesse stime rispetto ai dati effettivi <strong>Linee<\/strong> da.<\/p>\n\n<h2>Ordini concreti e controllo<\/h2>\n<p>Lavoro in modo riproducibile seguendo pochi passaggi chiari e verifico le statistiche JSON generate.<\/p>\n<pre><code>-- Creare istogrammi su singole colonne\nANALYZE TABLE orders UPDATE HISTOGRAM ON status WITH 32 BUCKETS;\nANALYZE TABLE orders UPDATE HISTOGRAM ON created_at WITH 128 BUCKETS;\n\n-- Pi\u00f9 colonne in un unico ciclo con lo stesso numero di bucket\nANALYZE TABLE orders UPDATE HISTOGRAM ON status, payment_method WITH 64 BUCKETS;\n\n-- Eliminare in modo mirato gli istogrammi\nANALYZE TABLE orders DROP HISTOGRAM ON status;\n<\/code><\/pre>\n<pre><code>-- Controllo visivo delle statistiche\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>Valuto l'effetto immediatamente con 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>La stima migliora <strong>righe<\/strong> Se si nota un cambiamento significativo e il piano passa, ad esempio, da una scansione completa (Full Scan) a una scansione per intervallo di indice (Index-Range-Scan) oppure modifica l'ordine dei join, la misura ha avuto successo. Se la differenza rimane significativa, aumento o riduco il numero di bucket e ricontrollo.<\/p>\n\n<h2>Esempio: stato degli ordini e valori rari<\/h2>\n<p>In una tabella degli ordini, lo stato \u201ecompleted\u201c \u00e8 spesso quello predominante, mentre \u201epending\u201c \u00e8 abbastanza frequente e \u201ecanceled\u201c \u00e8 molto raro; questo <strong>squilibrio<\/strong> senza un istogramma porta facilmente a selettivit\u00e0 errate. Se un\u2019API esegue una query su \u201ecanceled\u201c, l\u2019ottimizzatore potrebbe erroneamente scegliere una scansione completa della tabella, anche se sarebbe sufficiente un accesso mirato tramite indice. Con un istogramma singleton, MySQL riconosce che \u201ecanceled\u201c rappresenta solo una piccolissima percentuale e passa a una scansione dell\u2019intervallo dell\u2019indice oppure ottimizza l\u2019ordine dei join. In questo modo si riduce la latenza e non ho bisogno di un indice aggiuntivo per ogni <strong>Variante<\/strong> di un filtro. Nei dashboard con SLO rigidi, questa correzione comporta spesso notevoli vantaggi in termini di reattivit\u00e0.<\/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>Serie temporali e timestamp<\/h2>\n<p>Nel caso delle serie temporali, ci sono molti <strong>Accessi<\/strong> sulla base di dati recenti; le fasce temporali pi\u00f9 vecchie rimangono per lo pi\u00f9 inattive. Un istogramma Equi-Height su created_at o updated_at distingue gli intervalli di tempo molto frequentati da quelli utilizzati raramente. L\u2019ottimizzatore valuta quindi correttamente se sia opportuno eseguire una scansione per intervallo (Range Scan) o se una scansione della tabella (Table Scan) consenta di raggiungere l\u2019obiettivo pi\u00f9 rapidamente. Soprattutto in caso di filtri temporali parziali su tabelle di grandi dimensioni, riscontro evidenti cambiamenti nel piano di esecuzione e minori costi di I\/O. Ritengo che la <strong>Statistiche<\/strong> qui viene aggiornato pi\u00f9 spesso, perch\u00e9 l'attenzione si sposta sulle attivit\u00e0 quotidiane.<\/p>\n\n<h2>Partizioni, tipi di dati e collazioni<\/h2>\n<p>Sulle tabelle partizionate, esamino la distribuzione dei dati <strong>su tutte le partizioni<\/strong>. Forti variazioni (ad esempio su base mensile) possono appiattire gli istogrammi globali. Se singole partizioni sono estremamente selettive o estremamente ampie, verifico inoltre, utilizzando filtri di \u201cpartition pruning\u201d nella clausola WHERE, se la qualit\u00e0 del piano di esecuzione sia comunque adeguata. In generale, mi assicuro di formulare i filtri in modo che MySQL possa individuare le partizioni in una fase precoce <strong>escludere<\/strong> pu\u00f2.<\/p>\n<p>Gli istogrammi funzionano al meglio con tipi di dati scalari e comparabili (numeri, valori di data\/ora, VARCHAR\/CHAR con collazione adeguata). Nel caso di <strong>Dati LOB\/JSON<\/strong> preferisco puntare su <em>Colonne generate<\/em> con valori estratti e tipizzati e, se necessario, li correda di istogrammi o indici. Nel caso delle stringhe, la <strong>Raccolta<\/strong> la logica di confronto; a seconda della collazione, i valori possono coincidere (ad es. maiuscole\/minuscole). Mantengo la collazione coerente con le query per ottenere selettivit\u00e0 realistiche.<\/p>\n\n<h2>Limiti ed errori<\/h2>\n<p>Gli istogrammi rappresentano principalmente singole colonne con <strong>Costanti<\/strong> Bene; tuttavia, rappresentano le dipendenze tra pi\u00f9 colonne solo in misura limitata. In presenza di colonne fortemente correlate o di parametri dinamici (ad esempio, compilati dall\u2019applicazione) raggiungono i propri limiti. I campi booleani o le colonne con una distribuzione pressoch\u00e9 uniforme raramente traggono vantaggio da ulteriori analisi statistiche. Troppi intervalli e una manutenzione eccessiva possono a loro volta aumentare i tempi di gestione e analisi. Per questo motivo utilizzo gli istogrammi in modo mirato e verifico regolarmente i <strong>Effetto<\/strong> su modelli reali.<\/p>\n\n<h2>Controllo e aggiornamento dell'Optimizer<\/h2>\n<p>Controllo il <strong>Utilizzo<\/strong> dagli istogrammi, passando per ANALYZE TABLE e le opzioni dell\u2019ottimizzatore pertinenti, affinch\u00e9 il pianificatore utilizzi le statistiche in modo efficace. Nei sistemi con carico elevato, pianifico l\u2019aggiornamento in fasce orarie di minor traffico o in batch dopo carichi di dati di grandi dimensioni. Prima e dopo confronto i risultati di EXPLAIN e EXPLAIN ANALYZE per valutare le modifiche apportate all\u2019ordine delle join, alle fasi di filtraggio e ai modelli di costo. In caso di effetti negativi, intervengo immediatamente e ripristino una statistica precedente. Per un controllo pi\u00f9 approfondito della <a href=\"https:\/\/webhosting.de\/it\/mysql-optimizer-query-hosting-ottimizzazione-serverboost\/\">Opzioni dell'ottimizzatore<\/a> mi assicuro che le dipendenze con altre statistiche non causino errori inosservati <strong>Ipotesi<\/strong> produrre.<\/p>\n\n<h2>Monitoraggio, protezione dalla regressione e playbook<\/h2>\n<p>Mi sto costruendo un modello leggero <strong>Playbook<\/strong> per l'ambiente di produzione:<\/p>\n<ul>\n  <li>Definire la linea di base: prima di apportare modifiche, eseguire EXPLAIN ANALYZE, registrare il tempo di esecuzione, il numero di \u201erighe esaminate\u201c e il contatore dell\u2019handler.<\/li>\n  <li>Creare\/modificare un istogramma: concentrarsi specificatamente sulle colonne dei filtri, con intervalli conservativi.<\/li>\n  <li>Misurare subito dopo: piano, righe stimate rispetto a quelle effettive; un fattore di scostamento &gt;10 \u00e8 per me un segnale di allarme.<\/li>\n  <li>Regolazione di precisione: alzare\/abbassare i bucket; se necessario, modificare l'ordine dei filtri nella query.<\/li>\n  <li>Tenere pronto un rollback: DROP HISTOGRAM, nel caso in cui aumentino le latenze.<\/li>\n  <li>Automazione: eseguire ANALYZE durante le finestre di manutenzione, dopo i caricamenti ETL o dopo ondate significative di operazioni DML.<\/li>\n<\/ul>\n<p>Per analizzare le cause utilizzo <strong>Tracce dell'ottimizzatore<\/strong> e EXPLAIN ANALYZE, per verificare se il pianificatore, sulla base degli istogrammi, metta in primo piano la tabella selettiva corretta. Per i test A\/B, a titolo sperimentale, fisso l\u2019ordine dei join (STRAIGHT_JOIN) oppure impongo o disabilito singoli indici, al fine di valutare in modo isolato l\u2019effetto delle statistiche.<\/p>\n<p>Dal punto di vista organizzativo, si rivela utile un breve <strong>Registro delle modifiche<\/strong> Per ogni tabella: colonna, numero di bucket, momento, valori misurati prima\/dopo. Ci\u00f2 facilita le successive correzioni ed evita interazioni poco chiare.<\/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>Aspetti operativi: blocchi, costi, portabilit\u00e0<\/h2>\n<p>ANALYZE TABLE accetta una <strong>Blocco dei metadati<\/strong> sulla tabella, ma non blocca in modo permanente le normali operazioni di lettura\/scrittura. Per tabelle molto grandi, prevedo un tempo sufficiente; la generazione dell\u2019istogramma funziona con campioni ed \u00e8 limitata dalla memoria (parola chiave: memoria di lavoro interna per il calcolo). Lo spazio richiesto dalle statistiche stesse rimane moderato: da qualche dozzina a poche centinaia di kilobyte per colonna con 100\u2013256 bucket \u00e8 un valore di riferimento realistico. In totale, per\u00f2, faccio comunque i conti, perch\u00e9 molte colonne moltiplicate per molte tabelle danno come risultato <strong>metadati visibili<\/strong>.<\/p>\n<p>All'indirizzo <strong>Dump logici<\/strong> (mysqldump) gli istogrammi non vengono trasferiti insieme ai dati; dopo un ripristino, li ricreo in modo mirato. In caso di aggiornamento in-place, invece, vengono mantenuti. Dal punto di vista dei diritti, ho bisogno di privilegi sufficienti per eseguire ANALYZE TABLE sugli oggetti interessati; in ambienti rigorosamente regolamentati, integro questa attivit\u00e0 nelle pipeline di manutenzione.<\/p>\n\n<h2>Quando gli istogrammi non servono a nulla<\/h2>\n<p>Mi risparmio <strong>Istogrammi<\/strong> su colonne che contengono pochissimi valori e che possono comunque essere valutate con precisione. Anche nei casi in cui un buon indice copra gi\u00e0 insiemi minimi di risultati, un istogramma raramente offre un vantaggio aggiuntivo. Le distribuzioni uniformi non richiedono una granularit\u00e0 complessa. Nei sistemi altamente dinamici e con un'elevata attivit\u00e0 di scrittura, la manutenzione pu\u00f2 generare un carico superfluo se la avvio troppo frequentemente. In tali situazioni, impiego la <strong>Energia<\/strong> piuttosto nelle strategie di indicizzazione, nella progettazione delle query e nel caching.<\/p>\n\n<h2>Scheda riassuntiva in forma di tabella<\/h2>\n<p>Utilizzo il seguente <strong>Panoramica<\/strong> Per prendere decisioni rapide: quale tipo di istogramma \u00e8 pi\u00f9 adatto, come impostare i bucket e quali sono i costi associati. La tabella funge da promemoria durante le revisioni delle query problematiche. La aggiorno sulla base delle conoscenze acquisite tramite EXPLAIN ANALYZE e delle metriche di produzione. Nel farlo, tengo conto del fatto che le distribuzioni dei dati cambiano e che le ipotesi storiche diventano obsolete. Rimane fondamentale che la <strong>Qualit\u00e0 del progetto<\/strong> con misurazioni reali.<\/p>\n<table>\n  <thead>\n    <tr>\n      <th>Aspetto<\/th>\n      <th>Raccomandazione<\/th>\n      <th>Benefici<\/th>\n      <th>compromesso<\/th>\n      <th>Esempio<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>Tipo<\/td>\n      <td>Singleton in presenza di pochi valori dominanti<\/td>\n      <td>Percentuali di corrispondenza esatte per le categorie pi\u00f9 comuni<\/td>\n      <td>Poco utile in caso di aree continue<\/td>\n      <td>stato_ordine<\/td>\n    <\/tr>\n    <tr>\n      <td>Tipo<\/td>\n      <td>Equi-Height in presenza di dati distorti e continui<\/td>\n      <td>Stima pi\u00f9 accurata lungo l'intervallo di valori<\/td>\n      <td>Maggiori metadati in presenza di numerosi bucket<\/td>\n      <td>created_at, price<\/td>\n    <\/tr>\n    <tr>\n      <td>Secchielli<\/td>\n      <td>Inizia da 100, poi regola di conseguenza<\/td>\n      <td>Risoluzione bilanciata<\/td>\n      <td>Maggiore carico di analisi e di memoria con 512\u20131024<\/td>\n      <td>CON 100 SECCHI<\/td>\n    <\/tr>\n    <tr>\n      <td>Cura<\/td>\n      <td>Dopo modifiche significative ai dati, eseguire ANALYZE<\/td>\n      <td>Selettivit\u00e0 attuali<\/td>\n      <td>Pianificare le finestre di manutenzione<\/td>\n      <td>ANALYZE TABLE \u2026 UPDATE HISTOGRAM<\/td>\n    <\/tr>\n    <tr>\n      <td>Controllo<\/td>\n      <td>Verifica tramite COLUMN_STATISTICS<\/td>\n      <td>Trasparenza e revisione contabile<\/td>\n      <td>\u00c8 necessaria l'interpretazione JSON<\/td>\n      <td>INFORMATION_SCHEMA.COLUMN_STATISTICS<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Inserimento nel quadro generale del tuning<\/h2>\n<p>Io tratto <strong>Istogrammi<\/strong> come elemento fondamentale insieme agli indici, alla progettazione delle query, alla cache e ai parametri hardware. Spesso un buon istogramma modifica l\u2019ordine dei join, riduce l\u2019I\/O e garantisce tempi di risposta costanti. Tuttavia, non sostituisce n\u00e9 strategie di indicizzazione ben strutturate n\u00e9 uno schema efficiente. Chi analizza pi\u00f9 a fondo le decisioni relative alla pianificazione, trae vantaggio da <a href=\"https:\/\/webhosting.de\/it\/piani-di-esecuzione-delle-query-di-database-che-ospitano-informazioni-sulle-prestazioni-di-ottimizzazione\/\">Comprendere i piani di esecuzione<\/a> e mette a confronto i modelli di costo con i tempi effettivi. Verifico regolarmente se il <strong>Carichi di lavoro<\/strong> se siano ancora in linea con le statistiche o se siano necessari degli adeguamenti.<\/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>Scenari avanzati di join<\/h2>\n<p>Gli istogrammi risultano particolarmente utili quando sono coinvolte pi\u00f9 tabelle con filtri. Esempio:<\/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>Senza istogrammi, l\u2019ottimizzatore potrebbe sottovalutare la selettivit\u00e0 di o.status=\u2019canceled\u2018 o sovrastimare la percentuale di utenti tedeschi. Con un istogramma su <em>e.paese<\/em> e <em>o.status<\/em> (eventualmente anche su <em>o.created_at<\/em>) il progettista si rende solitamente conto che la combinazione \u00e8 estremamente selettiva. In pratica, osservo che MySQL determina prima il sottoinsieme pi\u00f9 piccolo (ad esempio tramite indice su users(country) o orders(status, created_at)) e solo successivamente esegue il join, invece di eseguire la scansione della tabella pi\u00f9 grande. Ci\u00f2 consente di risparmiare I\/O, buffer e CPU e stabilizza la latenza anche sotto carico.<\/p>\n<p>Poich\u00e9 gli istogrammi sono solo <strong>a colonna singola<\/strong> le strategie basate sugli indici rimangono importanti: un indice composto su (status, created_at) pu\u00f2 accelerare ulteriormente la scansione dell'intervallo. L'istogramma garantisce in questo caso soprattutto che l'ottimizzatore <em>Strategia<\/em> ritiene addirittura conveniente.<\/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>Sintesi per la pratica<\/h2>\n<p>Ho impostato <strong>MySQL<\/strong>-Utilizzo gli istogrammi quando l\u2019ottimizzatore sbaglia i calcoli con le statistiche predefinite e le distribuzioni asimmetriche generano piani errati. Con ANALYZE TABLE creo, aggiorno e rimuovo in modo mirato le statistiche sulle colonne che predominano nei filtri e nei join. Scelgo tra Singleton ed Equi-Height in base ai dati, mentre calibro il numero di bucket tramite misurazioni. Con EXPLAIN ANALYZE verifico se l\u2019ordine dei join, le posizioni dei filtri e le scansioni cambiano come desiderato. In questo modo ottengo con poco <strong>Spese generali<\/strong> query notevolmente pi\u00f9 veloci \u2013 spesso senza bisogno di ulteriori indici.<\/p>","protected":false},"excerpt":{"rendered":"<p>Scopri come gli istogrammi di MySQL forniscono all\u2019ottimizzatore statistiche precise, consentono di ottenere piani di query migliori e migliorano notevolmente l\u2019ottimizzazione SQL senza bisogno di indici aggiuntivi.<\/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":"102","_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\/it\/wp-json\/wp\/v2\/posts\/21018","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/comments?post=21018"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/posts\/21018\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/media\/21011"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/media?parent=21018"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/categories?post=21018"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/tags?post=21018"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}