Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
Diese Best Practices spiegeln die Empfehlungen eines interdisziplinären Teams erfahrener Looker wider. Diese Erkenntnisse basieren auf jahrelanger Erfahrung in der Zusammenarbeit mit Looker-Kunden – von der Implementierung bis hin zum langfristigen Erfolg. Die Best Practices sind so konzipiert, dass sie für die meisten Nutzer und Situationen funktionieren. Bei der Implementierung sollten Sie jedoch nach bestem Wissen und Gewissen vorgehen.
Abfrageleistung optimieren
Mit den folgenden Tipps für das Frontend und das Backend können Sie dafür sorgen, dass Abfragen optimal für Ihre Datenbank erstellt und ausgeführt werden:
Erstellen Sie Explores nach Möglichkeit mit many_to_one-Joins. Die beste Abfrageleistung wird in der Regel durch das Zusammenführen von Datenansichten von der untersten bis zur höchsten Detailebene (many_to_one) erzielt.
Maximieren Sie den Cache, um ihn nach Möglichkeit mit Ihren ETL-Richtlinien zu synchronisieren und den Traffic bei Datenbankabfragen zu reduzieren. Standardmäßig speichert Looker Abfragen eine Stunde lang im Cache. Sie können die Caching-Richtlinie steuern und die Aktualisierung von Looker-Daten mit Ihrem ETL-Prozess synchronisieren, indem Sie Datengruppen in Explores mit dem Parameter persist_with anwenden. So kann Looker noch stärker in die Backend-Datenpipeline eingebunden werden, sodass die Cachenutzung maximiert werden kann, ohne dass das Risiko besteht, veraltete Daten zu analysieren. Namensbasierte Caching-Richtlinien können auf ein gesamtes Modell und/oder auf einzelne Explores und persistente abgeleitete Tabellen (PDTs) angewendet werden.
Verwenden Sie PDTs für schnellere Abfragen. Wandeln Sie Explores mit vielen komplexen oder ineffizienten Joins oder Dimensionen mit Unterabfragen oder Unterauswahlen in PDTs um, damit die Datenansichten vor der Laufzeit zusammengeführt und bereit sind.
Vermeiden Sie es, Ansichten in Explores über zusammengesetzte Primärschlüssel zu verbinden, die in Looker definiert sind. Führen Sie stattdessen einen Join mit den Basisfeldern aus, die den zusammengesetzten Primärschlüssel aus der Ansicht bilden. Alternativ können Sie die Ansicht als PDT mit dem zusammengesetzten Primärschlüssel neu erstellen, der in der SQL-Definition der Tabelle und nicht in der LookML der Ansicht vordefiniert ist.
Verwenden Sie das Tool „In SQL Runner erklären“ für das Benchmarking. EXPLAIN erstellt eine Übersicht über den Abfrageausführungsplan Ihrer Datenbank für eine bestimmte SQL-Abfrage, mit der Sie Abfragekomponenten erkennen können, die optimiert werden können. Weitere Informationen finden Sie im Communitybeitrag SQL mit EXPLAIN optimieren.
Indexe deklarieren. Sie können sich die Indexe der einzelnen Tabellen direkt in Looker im SQL Runner ansehen. Klicken Sie dazu in einer Tabelle auf das Zahnradsymbol und wählen Sie Indexe anzeigen aus.
Die häufigsten Spalten, die von Indexen profitieren können, sind wichtige Datumsangaben und Fremdschlüssel. Wenn Sie diesen Spalten Indexe hinzufügen, wird die Leistung bei fast allen Abfragen gesteigert. Dies gilt auch für PDTs. LookML-Parameter wie indexes, sort keys und distribution können entsprechend angewendet werden.
Erhöhen Sie den Arbeitsspeicher, die Kerne und die E/A-Leistung (Eingabe/Ausgabe) von Datenbanken mit unzureichender Hardware oder nicht ausreichend bereitgestellten Ressourcen (z. B. AWS) für die Verarbeitung großer Datensätze, um die Abfrageleistung zu verbessern.
Leistung des Looker-Servers optimieren
Sie können auch Maßnahmen ergreifen, um die Leistung des Looker-Servers und der Looker-Anwendung zu optimieren:
Begrenzen Sie die Anzahl der Elemente in einem einzelnen Dashboard. Es gibt keine genaue Regel für die Definition der Anzahl, da das Design jedes Elements aufgrund verschiedener Faktoren den Arbeitsspeicherverbrauch beeinflusst. Dashboards mit 25 oder mehr Kacheln sind jedoch in Bezug auf die Leistung in der Regel problematisch.
Verwenden Sie die Funktion Dashboard automatisch aktualisieren strategisch. Wenn für ein Dashboard die automatische Aktualisierung verwendet wird, darf diese nicht schneller erfolgen als die ETL-Prozesse, die im Hintergrund ausgeführt werden.
Verwenden Sie Pivot-Tabellen strategisch und vermeiden Sie eine übermäßige Verwendung in Dashboard-Kacheln und Looks. Abfragen mit pivotierten Dimensionen verbrauchen mehr Arbeitsspeicher. Je mehr Dimensionen gepivotet werden, desto mehr Arbeitsspeicher wird beim Laden von Inhalten (Explores, Looks oder Dashboards) verbraucht.
Verwenden Sie Funktionen wie zusammengeführte Ergebnisse, benutzerdefinierte Felder und Tabellenkalkulationen sparsam.
Diese Funktionen sollen als Proof of Concept dienen, um Ihr Modell zu entwerfen.
Es empfiehlt sich, häufig verwendete Berechnungen und Funktionen in LookML zu hartcodieren. Dadurch wird SQL generiert, das in Ihrer Datenbank verarbeitet wird.
Zu viele Berechnungen können um den Java-Speicher der Looker-Instanz konkurrieren, was zu einer langsameren Reaktion der Looker-Instanz führt.
Begrenzen Sie die Anzahl der Ansichten in einem Modell, wenn eine große Anzahl von Ansichtsdateien vorhanden ist. Wenn Sie alle Datenansichten in einem einzigen Modell einbeziehen, kann die Leistung beeinträchtigt werden. Wenn ein Projekt eine große Anzahl von Ansichten enthält, sollten Sie in jedem Modell nur die erforderlichen Ansichtsdateien einschließen. Verwenden Sie strategische Benennungskonventionen für Dateinamen von Ansichten, um Gruppen von Ansichten in einem Modell einfach einbinden zu können. Ein Beispiel finden Sie in der Parameterdokumentation für includes.
Vermeiden Sie, in Dashboard-Kacheln und Looks standardmäßig eine große Anzahl von Datenpunkten zurückzugeben. Abfragen, die Tausende von Datenpunkten zurückgeben, verbrauchen mehr Arbeitsspeicher. Begrenzen Sie die Daten nach Möglichkeit, indem Sie
Filter auf der Frontendebene auf Dashboards, Looks und Explores anwenden und auf LookML-Ebene die Parameter required filters, conditionally_filter und sql_always_where verwenden.
Verwenden Sie die Option Alle Ergebnisse sparsam, da einige Abfragen sehr groß sein können und den Looker-Server bei der Verarbeitung überlasten.
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Schwer verständlich","hardToUnderstand","thumb-down"],["Informationen oder Beispielcode falsch","incorrectInformationOrSampleCode","thumb-down"],["Benötigte Informationen/Beispiele nicht gefunden","missingTheInformationSamplesINeed","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 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."]]
