Mantieni tutto organizzato con le raccolte
Salva e classifica i contenuti in base alle tue preferenze.
Queste best practice riflettono i consigli condivisi da un team interfunzionale di esperti Looker. Questi approfondimenti provengono da anni di esperienza di collaborazione con i clienti di Looker, dall'implementazione al successo a lungo termine. Le best practice sono scritte per essere utilizzate dalla maggior parte degli utenti e in diverse situazioni, ma devi fare la scelta migliore durante l'implementazione.
Ottimizzare le prestazioni delle query
Puoi assicurarti che le query vengano create ed eseguite in modo ottimale nel tuo database con i seguenti suggerimenti per frontend e backend:
Crea esplorazioni utilizzando le unioni many_to_one, se possibile. L'unione delle visualizzazioni dal livello più granulare al livello più alto di dettaglio (many_to_one) in genere offre le migliori prestazioni di query.
Massimizza la memorizzazione nella cache per sincronizzarti con i tuoi criteri ETL, ove possibile, per ridurre il traffico delle query del database. Per impostazione predefinita, Looker memorizza nella cache le query per un'ora. Puoi controllare il criterio di memorizzazione nella cache e sincronizzare gli aggiornamenti dei dati di Looker con il processo ETL applicando i gruppi di dati
all'interno delle esplorazioni utilizzando il parametro persist_with. In questo modo, Looker può integrarsi più strettamente con la pipeline di dati di backend, in modo da massimizzare l'utilizzo della cache senza il rischio di analizzare dati non aggiornati. I criteri di memorizzazione nella cache con nome possono essere applicati a un intero modello e/o a singole esplorazioni e tabelle derivate permanenti (PDT).
Utilizza i PDT per query più rapide. Converti le esplorazioni con molti join complessi o con scarso rendimento o con dimensioni con sottoquery o sottoselezioni in PDT in modo che le visualizzazioni siano pre-aggregate e pronte prima del runtime.
Evita di unire le visualizzazioni alle esplorazioni in base a chiavi primarie concatenate definite in Looker. Esegui invece il join sui campi di base che compongono la chiave primaria concatenata dalla visualizzazione. In alternativa, ricrea la visualizzazione come PDT con la chiave primaria concatenata predefinita nella definizione SQL della tabella anziché nel codice LookML di una visualizzazione.
Utilizza lo strumento Spiega in SQL Runner per il benchmarking. EXPLAIN genera una panoramica del piano di esecuzione delle query del database per una determinata query SQL, consentendo di rilevare i componenti delle query che possono essere ottimizzati. Scopri di più nel post della scheda Community Come ottimizzare SQL con EXPLAIN.
Dichiara gli indici. Puoi esaminare gli indici di ogni tabella direttamente in Looker da SQL Runner facendo clic sull'icona a forma di ingranaggio in una tabella e selezionando Mostra indici.
Le colonne più comuni che possono trarre vantaggio dagli indici sono le date importanti e le chiavi esterne. L'aggiunta di indici a queste colonne aumenterà le prestazioni per quasi tutte le query. Lo stesso vale per i PDT. I parametri LookML, come indexes, sort keys e distribution, possono essere applicati in modo appropriato.
Aumenta la memoria, i core e l'I/O (input/output) dei database con hardware insufficiente o risorse di provisioning necessarie (come AWS) per l'elaborazione di set di dati di grandi dimensioni, in modo da migliorare le prestazioni delle query.
Ottimizzare le prestazioni del server di Looker
Puoi anche adottare misure per garantire il rendimento ottimale del server e dell'applicazione Looker:
Limita il numero di elementi all'interno di una singola dashboard. Non esiste una regola precisa per definire il numero, perché il design di ogni elemento influisce sul consumo di memoria in base a una serie di fattori. Tuttavia, le dashboard con 25 o più riquadri tendono a essere problematiche in termini di prestazioni.
Utilizza la funzionalità di aggiornamento automatico della dashboard in modo strategico. Se una dashboard utilizza l'aggiornamento automatico, assicurati che non venga aggiornata più velocemente dei processi ETL in esecuzione in background.
Utilizza le pivot in modo strategico ed evita di utilizzarle eccessivamente nei riquadri della dashboard e nei look. Le query con dimensioni pivot consumano più memoria. Più dimensioni vengono pivotate, maggiore è la memoria utilizzata durante il caricamento dei contenuti (un'esplorazione, un look o una dashboard).
Utilizza con parsimonia funzionalità come i risultati dell'unione, i campi personalizzati e i calcoli tabulari.
Queste funzionalità sono pensate per essere utilizzate come prove del concetto per aiutarti a progettare il tuo modello.
È buona prassi codificare i calcoli e le funzioni di uso frequente in LookML, in modo da generare SQL da elaborare nel database.
Calcoli eccessivi possono competere per la memoria Java nell'istanza di Looker, causando una risposta più lenta dell'istanza.
Limita il numero di visualizzazioni incluse in un modello quando è presente un numero elevato di file di visualizzazione. L'inclusione di tutte le visualizzazioni in un unico modello può rallentare il rendimento. Quando in un progetto è presente un numero elevato di visualizzazioni, ti consigliamo di includere solo i file di visualizzazione necessari in ogni modello. Valuta la possibilità di utilizzare convenzioni di denominazione strategiche per i nomi dei file delle visualizzazioni, in modo da includere facilmente gruppi di visualizzazioni all'interno di un modello. Un esempio è descritto nella documentazione del parametro includes.
Evita di restituire un numero elevato di punti dati per impostazione predefinita nei riquadri della dashboard e nei look. Le query che restituiscono migliaia di punti dati consumeranno più memoria. Assicurati che i dati siano limitati, ove possibile, applicando
filtri frontend a dashboard, look ed esplorazioni e a livello di LookML con i parametri required filters, conditionally_filter e sql_always_where.
Scarica o invia query utilizzando l'opzione Tutti i risultati con parsimonia, poiché alcune query possono essere molto grandi e sopraffare il server di Looker durante l'elaborazione.
Per ulteriore assistenza per identificare la fonte dei problemi di rendimento, consulta la pagina Best practice della Panoramica del rendimento.
[[["Facile da capire","easyToUnderstand","thumb-up"],["Il problema è stato risolto","solvedMyProblem","thumb-up"],["Altra","otherUp","thumb-up"]],[["Difficile da capire","hardToUnderstand","thumb-down"],["Informazioni o codice di esempio errati","incorrectInformationOrSampleCode","thumb-down"],["Mancano le informazioni o gli esempi di cui ho bisogno","missingTheInformationSamplesINeed","thumb-down"],["Problema di traduzione","translationIssue","thumb-down"],["Altra","otherDown","thumb-down"]],["Ultimo aggiornamento 2025-07-31 UTC."],[],[],null,["# Optimize Looker performance\n\n\u003e *These best practices reflect recommendations shared by a cross-functional team of seasoned Lookers. These insights come from years of experience working with Looker customers from implementation to long-term success. The practices are written to work for most users and situations, but you should use your best judgment when implementing.*\n\nOptimize query performance\n--------------------------\n\n\nYou can ensure that queries are built and executed optimally against your database with the following frontend and backend tips:\n\n- Build Explores using [`many_to_one`](/looker/docs/reference/param-explore-join-relationship#many_to_one_(the_default_value)) joins whenever possible. Joining views from the most granular level to the highest level of detail (`many_to_one`) typically provides the best query performance.\n- Maximize caching to sync with your ETL policies wherever possible to reduce database query traffic. By default, Looker caches queries for one hour. You can control the caching policy and sync Looker data refreshes with your ETL process by applying [datagroups](/looker/docs/caching-and-datagroups) within Explores, using the [`persist_with`](/looker/docs/reference/param-explore-persist-with) parameter. This enables Looker to integrate more closely with the backend data pipeline, so cache usage can be maximized without the risk of analyzing stale data. Named caching policies can be applied to an entire model and/or to individual Explores and [persistent derived tables](/looker/docs/caching-and-datagroups#how_looker_uses_pdts_and_rebuilds_them) (PDTs).\n- Use Looker's [aggregate awareness](/looker/docs/aggregate_awareness) functionality to create roll-ups or summary tables that Looker can use for queries whenever possible, especially for common queries of large databases. You can also leverage aggregate awareness to drastically [improve the performance of entire dashboards](/looker/docs/reference/param-explore-aggregate-table#get_lookml_dashboard). See the [Aggregate awareness tutorial](/looker/docs/best-practices/aggregate-awareness-tutorial) for additional information.\n- Use [PDTs](/looker/docs/derived-tables#persistent_derived_table) for faster queries. Convert Explores with many complex or unperformant joins, or dimensions with subqueries or subselects, into PDTs so that the views are pre-joined and ready prior to runtime.\n- If your [database dialect supports incremental PDTs](/looker/docs/incremental-pdts#supported_database_dialects_for_incremental_pdts), configure [incremental PDTs](/looker/docs/incremental-pdts) to reduce the time Looker spends rebuilding PDT tables.\n- Avoid joining views into Explores on concatenated [primary keys](/looker/docs/reference/param-field-primary-key) that are defined in Looker. Instead, join on the base fields that make up the concatenated primary key from the view. Alternatively, recreate the view as a PDT with the concatenated primary key predefined in the table's SQL definition, rather than in a view's LookML.\n- Leverage the [Explain in SQL Runner tool](/looker/docs/sql-runner-manage-db#examining_an_execution_plan_using_explain) for benchmarking. `EXPLAIN` produces an overview of your database's query execution plan for a given SQL query, letting you detect query components that can be optimized. Learn more in the [How to optimize SQL with `EXPLAIN`](https://community.looker.com/technical-tips-tricks-1021/how-to-optimize-sql-with-explain-30772) Community post.\n- Declare indexes. You can look at the indexes of each table directly in Looker from [SQL Runner](/looker/docs/sql-runner-basics) by clicking the gear icon in a table and then selecting [**Show Indexes**](/looker/docs/sql-runner-manage-db#getting_table_information).\n\n \u003cbr /\u003e\n\n The most common columns that can benefit from indexes are important dates and foreign keys. Adding indexes to these columns will increase performance for almost all queries. This also applies for PDTs. LookML parameters, such as [`indexes`](/looker/docs/reference/param-view-indexes), [`sort keys`](/looker/docs/reference/param-view-sortkeys), and [`distribution`](/looker/docs/reference/param-view-distribution), can be applied appropriately.\n- Increase memory, cores, and I/O (input/output) of databases with insufficient hardware or necessary provisioned resources (such as AWS) for processing large datasets, to increase query performance.\n\nOptimize Looker server performance\n----------------------------------\n\n\nYou can also take measures to ensure that the Looker server and application are performing optimally:\n\n- Limit the number of elements within an individual dashboard. There is no precise rule for defining the number, because the design of each element impacts memory consumption based on a variety of factors; however, dashboards with 25 or more tiles tend to be problematic when it comes to performance.\n- Use the [dashboard auto refresh](/looker/docs/editing-user-defined-dashboards#autorefresh) feature strategically. If a dashboard uses auto refresh, make sure it refreshes no faster than the ETL processes running behind the scenes.\n- Use pivots strategically, and avoid over-using pivots within dashboard tiles and Looks. Queries with pivoted dimensions will consume more memory. The more dimensions that are pivoted, the more memory is consumed when content (an Explore, a Look, or a dashboard) is loaded.\n- Use features, such as [merge results](/looker/docs/merged-results), [custom fields](/looker/docs/custom-fields), and [table calculations](/looker/docs/table-calculations), sparingly. These features are intended to be used as proofs of concept to help design your model. It is best practice to hardcode any frequently used calculations and functions in LookML, which will generate SQL to be processed on your database. Excessive calculations can compete for Java memory on the Looker instance, causing the Looker instance to respond more slowly.\n- Limit the number of views included within a model when a large number of view files are present. Including all views in a single model can slow performance. When a large number of views are present within a project, consider including only the view files needed within each model. Consider using strategic naming conventions for view file names, to enable easy inclusion of groups of views within a model. An example is outlined in the [`includes`](/looker/docs/reference/param-model-include#things_to_know) parameter documentation.\n- Avoid returning a large number of data points by default within dashboard tiles and Looks. Queries that return thousands of data points will consume more memory. Ensure that data is limited wherever possible by applying frontend [filters](/looker/docs/filters-user-defined-dashboards#adding_dashboard_filters) to dashboards, Looks and Explores, and on the LookML level with [`required filters`](/looker/docs/filters-user-defined-dashboards#requiring_a_filter_value), [`conditionally_filter`](/looker/docs/reference/param-explore-conditionally-filter) and [`sql_always_where`](/looker/docs/reference/param-explore-sql-always-where) parameters.\n- Download or deliver queries using the [**All Results**](/looker/docs/downloading#all_results) option sparingly, as some queries can be very large and overwhelm the Looker server when processed.\n\n\nFor more help identifying the source of performance issues, check out the [Performance overview](/looker/docs/best-practices/how-to-optimize-looker-performance) Best Practices page."]]