Schreiben effizienter Abfragen
Lernziele
Nachdem Sie diese Lektion abgeschlossen haben, haben Sie Folgendes gelernt:
- Wie der Force.com Query Optimizer die Abfrageleistung optimiert.
- Welche Auswirkung die Verwendung selektiver Abfragen auf die Abfrageleistung hat.
- Wie das Tool Query Plan zur Bewertung von Suchabfragen eingesetzt wird.
Obergrenzen
Effiziente Abfragen funktionieren nicht nur besser, sondern tragen auch dazu bei sicherzustellen, dass Sie keine Probleme mit Obergrenzen bekommen. Denken Sie daran: Dies ist eine mandantenfähige Plattform, auf der jeder seinen Platz teilen muss. Und an erster Stelle unter den Dingen, die ein System schneller als sonst irgendetwas zum Absturz bringen können, steht eine schlecht funktionierende Abfrage. Und hier kommen die Obergrenzen ins Spiel.
Stellen Sie sich Obergrenzen als eine Art Ressourcen-Schiedsrichter vor. Sie sorgen dafür, dass sich jeder an die Regeln hält und dass jeder gleich viel vom Ressourcen-'Kuchen' erhält.
In dieser Lektion werden Sie lernen, was Sie tun können, um Ihre Suchabfragen zu optimieren, ohne dass Sie von den Grenzen in Ihre Schranken verwiesen werden müssen.
Der Force.com Query Optimizer
Die Backend-Datenbank von Salesforce verwendet Oracle, aber Force.com verwendet zum Bewerten kostenbasierter Abfragen seine eigene Query Optimizer-Version. Wie die meisten kostenbasierten Abfrageoptimierer basiert auch der von Salesforce verwendete auf Statistiken, die zu den erfassten Daten erstellt werden. Die meisten Statistiken werden wöchentlich erstellt, aber das System generiert auch Vorab-Abfragen, die stündlich gespeichert werden.
Der Query Optimizer bewertet SOQL-Abfragen und SOSL-Suchen. Er fungiert als eine Art Verkehrspolizist, indem er Abfragen zu den entsprechenden Indizes leitet. Er schaut sich alle eingehenden Abfragen an und weist jedem potenziellen Abfragepfad einen Kostenwert zu, der ihn identifiziert. Dann legt er mithilfe dieser Kosten fest, welcher Ausführungsplan verwendet wird.
Wir werden Ihnen hier jetzt nicht die Unwahrheit erzählen. Die Art und Weise, auf die der Query Optimizer Ausführungspläne auswählt und mit Schwellenwerten arbeitet, kann etwas kompliziert werden. Aber wir wissen, dass Sie als .NET-Entwickler sich der Herausforderung stellen werden. Sie können sich so eingehend damit beschäftigen, wie Sie möchten, indem Sie sich die Links im Abschnitt 'Ressourcen' anschauen, wenn wir hier fertig sind.
Bewährte Vorgehensweisen
Wir wissen, dass .NET-Entwickler sich nur zu gerne Gedanken über bewährte Vorgehensweisen machen. Sie lieben es, sich Herausforderungen zu stellen und sind immer auf der Suche nach dem besten Weg. Wir sind uns dessen voll bewusst. Also dachten wir uns, dass Sie bestimmt gerne erfahren möchten, welche bewährten Vorgehensweisen sich zum Erstellen schneller und effizienter Suchabfragen eignen.
Erstellen von selektiven Abfragen
Im ersten Kapitel haben wir uns mit SOQL-Anweisungen auseinandergesetzt und damit, wie Sie mithilfe der WHERE-Klausel Filter anwenden können. Mithilfe der AND- und OR-Klauseln können Sie sogar mehrere Felder kombinieren.
Ja, und es wird Sie nicht überraschen zu hören, dass es gut ist, wenn Sie mehr Felder in Ihrer WHERE-Klausel haben. Je weniger Daten bei Ihrer Abfrage ausgegeben werden, umso besser ist es offensichtlich. Was Sie aber vielleicht nicht wissen, ist, dass nicht alle Felder gleich sind. Einige Felder sind sozusagen 'leistungsstarke' Felder. Wenn Sie diese 'leistungsstarken' Felder in der WHERE-Klausel verwenden, sind ihre Abfragen superduper-schnell.
Und was macht diese 'leistungsstarken' Felder denn nun so leistungsstark? Indizes natürlich.
Bei allen Standard- und benutzerdefinierten Tabellen sind bestimmte automatisch als indiziert gekennzeichnet. Zu diesen Feldern gehören die folgenden:
| Indiziertes Feld | Beschreibung |
|---|---|
| Id | Eindeutiges vom System generiertes, aus 18 Zeichen bestehendes Feld. Dies ist der primäre Schlüssel für das Objekt. |
| Name | Textbasiertes Feld |
| OwnerId | Referenz zum Eigentümer des Objekts. |
| CreatedDate | Datum und Uhrzeit der Erstellung des Datensatzes. |
| SystemModStamp | Schreibgeschütztes Feld, das das Datum enthält, an dem der Datensatz zuletzt aktualisiert wurde. Dieses Feld ist anders als das ähnliche Feld LastModifiedDate indiziert, sodass Sie dieses Feld in Ihren Abfragen verwenden sollten. |
| RecordType | Die ID des RecordType. RecordTypes dienen dazu, bestimmten Benutzern verschiedene UI-Ergebnisse anzubieten. |
| Master-Detail-Felder | Fremdschlüsselfeld, das zum Angeben einer Master-Detail-Beziehung dient. |
| Nachschlagefelder | Fremdschlüsselfeld, das zum Angeben einer Nachschlagebeziehung dient. |
| Eindeutige Felder | Benutzerdefinierte Felder können, wenn sie erstellt werden, als eindeutig gekennzeichnet werden, wodurch sie automatisch indiziert werden. |
| Externe ID-Felder | Genau wie eindeutige Felder können diese benutzerdefinierten Felder mit einer externen ID gekennzeichnet werden; sie werden hauptsächlich zu Integrationszwecken eingesetzt. |
Jedes Mal, wenn Sie eines dieser indizierten Felder in der WHERE-Klausel Ihrer Abfrage verwenden, erhöhen Sie die Chance, dass ihre Abfrage als selektiv gilt und dass kein Scan der gesamten Tabelle sondern ein Index zum Einsatz kommt. Wir können nicht genug betonen, wie wichtig dies ist, wenn Sie es mit großen Datenbanken zu tun haben.
Hinweis: Es ist möglich, dass Salesforce-Kunden beim Salesforce-Support einen benutzerdefinierten Index beantragen, indem Sie einen Kundenvorgang anlegen und die SOQL-Abfrage mit dem indizierten Feld eingeben.
Indexselektivitäts-Ausnahmen
Die Verwendung eines indexierten Felds in Ihrer Abfrage macht es nicht automatisch golden. Sie können in Ihren Abfragen Dinge tun, die dazu führen, dass sie nicht selektiv und damit anfällig für die gefürchteten Scans der gesamten Tabelle sind. Versuchen Sie immer, diese Dinge beim Erstellen Ihrer Abfragen zu vermeiden.
- Abfragen nach Null-Zeilen – Abfragen, die nach Datensätzen suchen, in denen das Feld leer oder gleich Null ist. Beispiel:
SELECT Id, Name FROM Account WHERE Custom_Field__c = null - Negative Filter-Operatoren – Verwendung von Operatoren wie z. B. !=, NOT LIKE oder EXCLUDES in Ihren Abfragen. Beispiel:
SELECT CaseNumber FROM Case WHERE Status != ‘New’ - Platzhalter vorne – Abfragen, die Platzhalter vorne wie z. B. diesen verwenden:
SELECT Id, LastName, FirstName FROM Contact WHERE LastName LIKE ‘%smi%’ - Textfelder mit Vergleichsoperatoren – Verwenden von Vergleichsoperatoren, wie z. B. >, <, >=, or <= mit textbasierten Feldern. Beispiel:
SELECT AccountId, Amount FROM Opportunity WHERE Order_Number__c > 10
Abfrageplan-Tool
Unsere Freundin, die Entwicklerkonsole, enthält ein nettes kleines Tool, mit dem Sie Ihre Abfragen beschleunigen können. Mit diesem Tool können Sie hinter die Kulissen schauen und sehen, wie der Query Optimizer funktioniert. Das Abfrageplan-Tool ist nicht standardmäßig aktiviert. Aktivieren Sie es, indem Sie Folgendes tun.
- Wählen Sie im Menü "Setup" Developer Console aus, um die Entwicklerkonsole zu öffnen.
- Wählen Sie in der Entwicklerkonsole Help > Preferences aus.
- Wählen Sie Enable Query Plan aus und vergewissern Sie sich, dass der Eintrag auf 'Wahr' gesetzt ist.
- Klicken Sie auf Save (Speichern).
- Bestätigen Sie auf der Registerkarte 'Query Editor', dass sich die Schaltfläche 'Query Plan' jetzt neben der Schaltfläche 'Execute' befindet.
Jetzt, da das Tool 'Query Plan' aktiviert ist, können Sie es zum Bewerten von Abfragen verwenden. Beginnen wir, indem wir es zum Bewerten einer schlecht funktionierenden Abfrage verwenden.
- Klicken Sie in der Entwicklerkonsole im unteren Bereich auf die Registerkarte Query Editor.
- Löschen Sie den vorhandenen Code und fügen Sie den folgenden Ausschnitt ein:
SELECT Id, CaseNumber FROM Case WHERE Status != 'New' - Klicken Sie auf Query Plan.
Im Dialogfeld 'Query Plan' wird eine Tabelle angezeigt, in der die Kosten der Abfrage und der Umstand, dass ein Tabellenscan durchgeführt werden wird, angezeigt sind. Das ist nicht gut! Lesen Sie die Hinweise im Bildfenster unten, in denen die Ergebnisse näher erläutert sind.
Schauen wir uns nun eine andere Abfrage an, die dieselben Ergebnisse ausgibt wie die erste Abfrage.
- Klicken Sie im Bildfenster unten auf die Registerkarte Query Editor.
- Löschen Sie den vorhandenen Code und fügen Sie den folgenden Ausschnitt ein:
SELECT Id, CaseNumber FROM Case WHERE IsClosed = true - Klicken Sie auf Query Plan.
Im Dialogfeld 'Query Plan' wird eine Tabelle angezeigt, in der die Kosten der Abfrage aufgeführt sind; dieses Mal sehen Sie jedoch eine weitere Zeile, in der angegeben wird, dass es möglich ist, einen Index zu verwenden.
Beide Abfragen, die wir durch das Abfrageplan-Tool haben laufen lassen, ergaben dieselbe Anzahl an Zeilen, aber aufgrund der Felder und Operatoren, die wir gewählt haben, unterschieden sich die Ausführungspläne ziemlich. Diese Unterschiede scheinen gering, da Sie nur ganz wenige Daten in Ihrer Entwicklungsorganisation haben, aber wenn Sie Abfragen in Organisationen mit Millionen von Datensätzen vergleichen, können diese Unterschiede spielentscheidend sein.
Weitere Informationen darüber, was jede Spalte im Abfrageplan-Tool preisgibt, finden Sie im Abschnitt 'Ressourcen' unter dem Link zum Abfrageplan-Tool.
Weitere Infos
Versuchen Sie nach Möglichkeit, Abfragen mit nicht deterministischen Formelfeldern zu vermeiden. Formelfelder sind benutzerdefinierte Felder mit denen Sie den Wert eines Felds zur Laufzeit dynamisch berechnen können. Diese Feldtypen sind in den meisten Organisationen tendenziell beliebt und können leicht überstrapaziert werden. Ein Formelfeld gilt als nicht deterministisch, wenn sein Wert sich im Laufe der Zeit verändert. Schauen Sie sich den Link im Abschnitt 'Ressourcen' zu den bewährten SOQL-Vorgehensweisen: 'Nulls and Formula Fields' an, um weitere Informationen zu erhalten.
Leider können Sie das Abfrageplan-Tool nicht zum Bewerten von SOSL-Abfragen verwenden, aber das heißt nicht, dass Sie die Leistung mit diesen Abfragetypen außer Acht lassen sollen. Erfahren Sie mehr darüber, was beim Schreiben von SOSL-Abfragen zu vermeiden ist, indem Sie den im Abschnitt 'Ressourcen' genannten Link 'Best Practices and Performance Tips' lesen.
