Loading

FAQ sur l’outil de plan de requête de la Developer Console

Date de publication: Aug 30, 2024
Description

L’outil de plan de requête de la Developer Console peut aider à accélérer les requêtes SOQL effectuées sur des volumes importants. Utilisez l’outil de plan de requête pour optimiser et accélérer les requêtes effectuées sur des volumes importants.

 

Activation et utilisation de l’outil de plan de requête

  1. Dans la Developer Console, cliquez sur Aide | Préférences
  2. Définissez Activer le plan de requête sur TRUE.


Une fois activé dans la Developer Console, vous pouvez accéder à l’outil de plan de requête dans l’onglet Éditeur de requête de la console.

Pour utiliser l’outil de plan de requête, entrez simplement une requête dans l’onglet Éditeur de requête et cliquez sur Plan de requête pour afficher toutes les opérations de requête et le coût de chacune pour le SOQL fourni.

 
Résolution

Pourquoi utiliser l’outil de plan de requête

Utilisez cet outil pour vérifier le plan de requête pour toutes les requêtes SOQL qui s’exécutent lentement. Il vous fournira un aperçu des différents plans et, si certains des filtres sont indexés, il vous indiquera le coût d’utilisation de l’index par rapport à une analyse de tableau complète.

Si le coût de l’analyse de tableau est inférieur à celui de l’index et que la requête expire, ou si vous avez un autre filtre sélectif dans cette requête qui n’est pas indexé mais qui pourrait l’être, vous devrez effectuer une analyse plus approfondie sur l’utilisation d’autres filtres pour améliorer la sélectivité.
 

Pour déterminer si un filtre est sélectif :

  • Déterminez s’il a un index.
  • Si le filtre est défini sur un champ standard, il aura un index s’il s’agit d’une clé primaire [ID, Nom, Ownerld], d’une clé étrangère (CreatedById, LastModifiedById, recherche, relation principal-détails) et d’un champ d’audit (CreatedDate, SystemModstamp).
  • Les champs personnalisés auront un index s’ils ont été marqués comme Unique ou ID externe
  • Si le filtre n’a pas d’index, il ne sera pas pris en compte pour l’optimisation.
  • Si le filtre a un index, déterminez le nombre d’enregistrements qu’il renverrait :
  • Pour un index standard, le seuil est de 30 pour cent du premier million d’enregistrements ciblés et de 15 pour cent de tous les enregistrements après ce premier million. En outre, le seuil de sélectivité pour un index standard atteint un maximum de 1 million d’enregistrements ciblés au total, que vous ne pourriez atteindre que si vous disposiez de plus de 5,6 millions d’enregistrements au total.
  • Pour un index personnalisé, le seuil de sélectivité est de 10 pour cent du premier million d’enregistrements ciblés et de 5 pour cent de tous les enregistrements après ce premier million. En outre, le seuil de sélectivité pour un index personnalisé atteint 333 333 enregistrements ciblés, que vous ne pourriez atteindre que si vous disposiez de plus de 5,6 millions d’enregistrements.
  • Si le filtre dépasse le seuil, il ne sera pas pris en compte pour l’optimisation.
  • Si le filtre ne dépasse pas le seuil, ce filtre EST sélectif et l’optimiseur de requêtes le prendra en considération pour l’optimisation.
 

Que signifie tout cela ?

L’outil de plan de requête affichera une liste des plans disponibles que notre optimiseur de requêtes peut utiliser pour la requête fournie et sera organisé par coût croissant.

Chaque plan contiendra des informations sur la cardinalité, le type d’opération, le coût, le type sObject, etc. Chaque plan a un type d’opération principal, par exemple, un index de champ ou une analyse complète de tableau. Le plan avec le coût le plus bas est le plan utilisé pour assurer l’exécution de la requête.

 
Cardinalité
Champs
Type d’opération principal
Coût
Cardinalité sObject
Type sObject
Nombre estimé d’enregistrements renvoyés par le type d’opération principal.
Par exemple, le nombre d’enregistrements renvoyés si vous utilisez un tableau d’index.
 
Le ou les champs indexés utilisés par l’optimiseur de requêtes. Si le type d’opération principal est Index, la valeur des champs est Index. Sinon, la valeur des champs est null.
Type d’opération principal que Salesforce utilisera pour optimiser la requête.
  • Index : la requête utilisera un index sur l’objet interrogé.
  • Partage : la requête utilisera un index basé sur les règles de partage associées à l’utilisateur qui exécute la requête. S’il existe des règles de partage qui limitent les enregistrements auxquels l’utilisateur peut accéder, Salesforce peut utiliser ces règles pour optimiser la requête.
  • TableScan : la requête analysera tous les enregistrements pour l’objet interrogé.
  • Autre : la requête utilisera des optimisations internes à Salesforce.
Coût de la requête par rapport au seuil de sélectivité de l’optimiseur de requêtes Force.com. Les valeurs supérieures à 1 signifient que la requête ne sera pas sélective.
Nombre d’enregistrements approximatif pour l’objet interrogé.
Nom de l’objet interrogé.
 

 

Comment le coût est-il déterminé ?

Chaque plan a sa propre valeur de coût. Cette valeur de coût est dérivée des dernières statistiques de base de données (DB) rassemblées sur le tableau et les valeurs. Le plan avec le coût le plus bas sera le plan utilisé. Si le coût est supérieur à 1, cela signifie que la requête ne sera pas sélective.

 

Le champ indexé n’apparaît pas dans la liste des plans

Si la requête que vous avez fournie contient un champ indexé dans les filtres, le plan ne sera affiché pour ce champ que si vous utilisez une opération prise en charge contre ce champ.

Voici une liste de opérations non prises en charge :

  • L’index personnalisé ne sera jamais utilisé lorsque des comparaisons sont effectuées avec un opérateur tel que « NOT EQUAL TO »
  • L’index personnalisé ne sera jamais utilisé lorsque des comparaisons sont effectuées avec une valeur null comme "Name = ’’"
  • Les caractères génériques « % » placés en tête de valeur sont inefficaces et rendent les conditions de filtrage non sélectives
  • Lors de l’utilisation d’une comparaison OR, tous les filtres doivent être indexés et sous le seuil de 10 %. . Si vous avez un champ non indexé ou si un filtre est au-dessus des 10 %, le plan ne sera pas affiché.

 

L’outil de plan de requête affiche-t-il les candidats à l’indexation ou les champs qui peuvent être indexés ?

L’outil de plan de requête n’affiche que les statistiques des champs indexés dans la section du plan, et non les champs qui pourraient être indexés. Il ne fournit pas d’informations sur les champs qui peuvent être indexés.

Veuillez consulter la section Comment rendre ma requête SOQL sélective pour déterminer les champs pouvant être indexés.

 

Exemples et interprétation des résultats du plan de requête 

Les exemples suivants utilisent 2 champs indexés. Une case à cocher (InActiveAcc__c) et une liste de sélection (Account_Hierarchy__c) sur le sObject Compte.

Remarque : vous pouvez trouver d’autres exemples de requêtes dans l’article original sur la version pilote du paramètre de feedback sur la ressource query, à partir duquel ce nouvel outil Developer Console a évolué.

 

Exemple de requête 1

SELECT count() FROM Account WHERE Account_Hierarchy__c = ’Parent’


Scénario : Un champ indexé avec une variable de liaison sélective

Le champ « Account_Hierarchy__c » est indexé et a donc été pris en considération pour un plan avec le type d’opération principal « Index ». Le champ indexé a un coût inférieur à celui de TableScan, de sorte que l’index sera utilisé par l’optimiseur de requêtes pour cette requête sur l’objet Compte de 50 088 lignes.

 

Exemple de requête 2

SELECT count() FROM Account WHERE InActiveAcc__c = true AND Account_Hierarchy__c = ’Parent’


Scénario : 2 champs indexés, 1 sélectif

Que se passe-t-il si plusieurs filtres simples sont sélectifs ? Si plusieurs filtres s’avèrent sélectifs, l’optimiseur de requêtes choisit celui qui présente le coût le plus bas pour assurer le plan d’exécution de la requête.

 

Exemple de requête 3

SELECT count() FROM Account WHERE InActiveAcc__c = true AND Account_Hierarchy__c != ’Parent’ **NOTE: Using unsupported operation on index**


Scénario : 2 champs indexés, 1 sélectif, MAIS avec une opération non prise en charge

L’index sur Account_Hierarchy__c n’est pas utilisé ou pris en considération en raison de l’opération non prise en charge de « ! = ». Notez également que InActiveAcc__c sera utilisé mais que son coût est supérieur à 1. Comme mentionné précédemment, le filtre n’est pas sélectif mais sera utilisé.

 

Exemple de requête 4

SELECT count() FROM Account WHERE Account_Hierarchy__c = ’Child’


Scénario : 1 champ indexé utilisant une variable de liaison non sélective (> 10 % du nombre de lignes du sObject)

Ici, le champ indexé Account_Hierarchy__c affiche un coût beaucoup plus élevé qu’une analyse complète du tableau. La raison en est que l’index n’est pas sélectif avec la variable de liaison « Enfant » (Child), résultant en plus de 10 % du tableau complet. La base de données exécutera une analyse complète du tableau pour cette requête, ce qui, en fonction de la taille complète du tableau, peut entraîner des performances médiocres.
Numéro d’article de la base de connaissances

000386864

 
Chargement
Salesforce Help | Article