Écriture de requêtes efficaces
Objectifs de formation
Une fois cette unité terminée, vous pourrez :
- Comprendre comment Force.com Query Optimizer optimise les performances des requêtes.
- Comprendre l'impact de l'utilisation de requêtes sélectives sur les performances des requêtes.
- Comprendre l'utilisation de l'outil Query Plan pour évaluer les requêtes de recherche.
Limitations
Non seulement l'exécution de requêtes efficaces est plus rapide, mais elles permettent d'éviter les problèmes en respectant les limitations de gouverneur. N'oubliez pas que la plate-forme est mutualisée et que chacun doit partager l'espace. Des requêtes mal exécutées sont la principale cause de défaillance du système. Les limitations du gouverneur prennent ici tout leur sens.
Elles servent à arbitrer les ressources. Elles vérifient que chacun respecte les règles et reçoit une part égale des ressources disponibles.
Dans cette unité, nous allons apprendre à optimiser vos requêtes de recherche afin d'éviter tout problème avec les limitations imposées.
Le moteur Force.com Query Optimizer
La base de données back-end de Salesforce utilise Oracle, mais Force.com utilise son propre moteur d'optimisation afin d'évaluer les requêtes en fonction du coût. Comme la plupart des moteurs d'optimisation de requêtes basés sur le coût, celui que Salesforce utilise s'appuie sur des statistiques récupérées sur les données. La plupart des statistiques sont collectées toutes les semaines, mais le système génère également des pré-requêtes qui sont mises en cache toutes les heures.
Le moteur Query Optimizer évalue les requêtes SOQL et les recherches SOSL. Il agit comme un agent de la circulation pour acheminer les requêtes vers les index appropriés. Il examine toutes les requêtes entrantes et attribue une valeur de coût à chaque chemin de requête potentiel qu'il identifie. Il utilise ensuite ces coûts pour déterminer le plan d'exécution à utiliser.
Nous n'allons pas vous mentir. La méthode utilisée par le moteur Query Optimizer pour sélectionner les plans d'exécution et utiliser des seuils peut s'avérer complexe. En tant que développeur .NET, nous savons que vous pouvez relever ce défi. Vous pourrez explorer tous les détails en suivant les liens de la section Ressources une fois cette unité terminée.
Meilleures pratiques
Nous sommes conscients que les développeurs .NET aiment s'informer des meilleures pratiques. Vous aimez les défis et vous recherchez toujours la méthode la plus efficace. Nous le comprenons. Nous vous proposons par conséquent de suivre nos meilleures pratiques pour créer des requêtes de recherche rapides et efficaces.
Création de requêtes sélectives
Dans la première unité, nous avons examiné les instructions SOQL et comment appliquer des filtres en utilisant la clause WHERE. Vous pouvez même combiner plusieurs champs en utilisant les clauses AND et OR.
Vous ne serez pas surpris d'apprendre que des champs supplémentaires dans votre clause WHERE sont une bonne chose. Évidemment, moins votre requête renvoie de données, mieux c'est. Cependant, vous ignorez peut-être que les champs ne sont pas tous les mêmes. Certains peuvent être considérés comme des champs « avec pouvoir ». Si vous utilisez ces champs puissants avec la clause WHERE, vos requêtes sont extrêmement rapides.
Qu'est-ce qui rend ces champs avec pouvoir si puissants ? Les index bien sûr.
Pour tous les tableaux standard et personnalisés, certains champs sont automatiquement marqués comme indexés. Parmi ces champs figurent les suivants :
| Champ indexé | Description |
|---|---|
| Id | Champ de 18 caractères uniques générés par le système. Il correspond à la clé primaire de l'objet. |
| Nom | Champ de texte. |
| OwnerId | Référence au propriétaire de l'objet. |
| CreatedDate | Date et heure de création de l'enregistrement. |
| SystemModStamp | Champ en lecture seule qui contient la date de dernière mise à jour de l'enregistrement. Ce champ est indexé, contrairement au champ semblable LastModifiedDate. Par conséquent, utilisez-le dans vos requêtes. |
| RecordType | ID de RecordType. Les types d'enregistrement sont utilisés pour fournir des résultats d'interface utilisateur différents à certains utilisateurs. |
| Champs principal-détails | Champ de clé étrangère utilisé pour indiquer une relation principal-détails. |
| Champs de référence | Champ de clé étrangère utilisé pour indiquer une relation de référence. |
| Champs uniques | Les champs personnalisés peuvent être marqués comme uniques lors de la création, ce qui les rend automatiquement indexés. |
| Champs ID externe | Semblables aux champs uniques, ces champs personnalisés peuvent être marqués en tant qu'ID externe et sont utilisés essentiellement pour l'intégration. |
Chaque fois que vous utilisez l'un de ces champs indexés dans la clause WHERE de votre requête, vous augmentez les chances que votre requête soit considérée comme sélective et la probabilité d'utilisation d'un index au lieu d'un scan de tableau complet. Nous ne soulignerons jamais assez l'importance de ce point en présence de bases de données volumineuses.
Remarque : Les clients de Salesforce peuvent demander au service de support un index personnalisé en créant une requête de support et en insérant la requête SOQL dans le champ indexé.
Exceptions de sélectivité d'index
L'utilisation d'un champ d'index dans votre requête n'est pas toujours la meilleure solution. Vous pouvez configurer vos requêtes pour les rendre non sélectives et les exposer ainsi au redouté scan de tableau complet. En créant vos requêtes, essayez toujours d'éviter les éléments suivants :
- Recherche de lignes nulles : requêtes qui recherchent les enregistrements dans lesquels le champ est vide ou nul. Par exemple :
SELECT Id, Name FROM Account WHERE Custom_Field__c = null - Opérateurs de filtrage négatifs : utilisation d'opérateurs tels que !=, NOT LIKE ou EXCLUDES dans vos requêtes. Par exemple :
SELECT CaseNumber FROM Case WHERE Status != ‘New’ - Caractères génériques d'en-tête : requêtes qui utilisent un caractère générique d'en-tête tel que :
SELECT Id, LastName, FirstName FROM Contact WHERE LastName LIKE ‘%smi%’ - Champs de texte avec des opérateurs de comparaison : utilisation d’opérateurs de comparaison, tels que >, <, >= ou <= avec des champs de texte. Par exemple :
SELECT AccountId, Amount FROM Opportunity WHERE Order_Number__c > 10
Outil Query Plan
Notre amie la Developer Console contient un outil qui accélère vos requêtes. Il permet d'observer comment fonctionne en arrière-plan le moteur Query Optimizer. L'outil Query Plan n'est pas activé par défaut. Pour l'activer, procédez comme suit :
- Dans le menu Configuration, sélectionnez Developer Console pour ouvrir la Developer Console.
- Dans la Developer Console, sélectionnez Aide > Préférences.
- Sélectionnez Enable Query Plan, puis vérifiez qu'il est défini sur true.
- Cliquez sur Enregistrer.
- Sous l'onglet Query Editor, assurez-vous que le bouton Query Plan est désormais affiché en regard du bouton Execute.
L'outil Query Plan est désormais activé, vous pouvez l'utiliser pour évaluer les requêtes. Commençons par l'utiliser pour évaluer une requête qui fonctionne mal.
- Dans la Developer Console, cliquez sur l'onglet Query Editor dans le volet inférieur.
- Supprimez le code existant, puis insérez l’extrait suivant :
SELECT Id, CaseNumber FROM Case WHERE Status != 'New' - Cliquez sur Query Plan.
La boîte de dialogue Query Plan affiche un tableau qui indique le coût de la requête et qu'il va exécuter un TableScan. Cette action n'est pas recommandée. Dans le volet inférieur, consultez les notes qui expliquent les résultats.
Examinons maintenant une autre requête qui renvoie les mêmes résultats que la première.
- Cliquez sur l'onglet Query Editor dans le volet inférieur.
- Supprimez le code existant, puis insérez l’extrait suivant :
SELECT Id, CaseNumber FROM Case WHERE IsClosed = true - Cliquez sur Query Plan.
La boîte de dialogue Query Plan affiche un tableau qui indique le coût des requêtes, mais cette fois une autre ligne indique qu'il est possible d'utiliser un index.
Les deux requêtes que nous avons exécutées via Query Plan ont renvoyé le même nombre de lignes, mais les plans d'exécution sont sensiblement différents en raison des champs et des opérateurs que nous avons choisis. Ces différences paraissent mineures en raison du nombre limité de données que contient votre organisation de développement. Cependant, si vous comparez ces requêtes dans des organisations contenant des millions d'enregistrements, ces différences sont considérables.
Pour plus d'informations sur chaque colonne que l'outil Query Plan affiche, suivez le lien Query Plan Tool dans la section Ressources.
En savoir plus
Essayez toujours d'éviter la création de requêtes avec des champs de formule non déterministes. Les champs de formule sont des champs personnalisés qui permettent de calculer dynamiquement la valeur d'un champ à l'exécution. La popularité de ces champs augmente dans la plupart des organisations et ils ont tendance à être trop utilisés. Un champ de formule est considéré comme non déterministe lorsque sa valeur varie au fil du temps. Pour plus d'informations, suivez le lien Force.com SOQL Best Practices: Nulls and Formula Fields dans la section Ressources.
Malheureusement, vous ne pouvez pas utiliser l’outil Query Plan pour évaluer les requêtes SOSL. Cela ne signifie pas pour autant que vous devez ignorer les performances de ces types de requête. Pour en savoir plus sur les éléments à éviter en écrivant des requêtes SOSL, suivez les liens Best Practices et Performance Tips dans la section Ressources.