Amélioration des performances des requêtes SOQL à l’aide d’un index personnalisé

Remarque importante :

Bien que cet article explique le fonctionnement général de l’optimiseur de requêtes Salesforce SOQL, son comportement peut changer sans préavis pour permettre des améliorations de performances supplémentaires. Les développeurs sont invités à utiliser la vue de plan de requête (disponible depuis la version Summer ’14) dans la Developer Console pour pouvoir régler les requêtes non sélectives à partir des informations fournies par l’optimiseur au moment de la génération du plan de requête pour la requête SOQL concernée.

En outre, les index peuvent augmenter le coût des opérations DML et, dans certains cas, l’optimiseur de requêtes doit procéder différemment en fonction des index qui peuvent avoir un impact sur les performances.

Critères de requête SOQL sélective

Une requête est sélective lorsque l’un des filtres de requête porte sur un champ indexé et que le filtre de requête réduit le nombre de lignes obtenues en dessous d’un seuil défini par le système. Les performances de la requête SOQL s’améliorent lorsqu’au moins deux filtres utilisés dans la clause WHERE remplissent les conditions mentionnées.

Le seuil de sélectivité est de 10 % des enregistrements pour le premier million d’enregistrements et de moins de 5 % des enregistrements après le premier million d’enregistrements, et peut atteindre jusqu’à un maximum de 333 000 enregistrements. Dans certains cas, par exemple avec un filtre de requête qui est un champ standard indexé, le seuil peut être plus élevé. De plus, le seuil de sélectivité est sujet à changement.

Considérations relatives aux index personnalisés pour les requêtes SOQL sélectives

Les champs suivants sont indexés par défaut :

Clés primaires (champs ID, Nom et Propriétaire).
Clés étrangères (champs de recherche ou de relation principal-détails).
Dates d’audit (telles que SystemModStamp).
Champs personnalisés marqués comme ID externe ou Unique.

Le support Salesforce peut ajouter des index personnalisés à la demande des clients

Lors de la création d’une requête auprès du support, veillez à inclure la requête SOQL dont le champ doit être indexé en tant que filtre dans la clause WHERE. Veillez également à inclure les valeurs de liaison, si nécessaire.
Consultez la liste de contrôle dans Comment rendre une requête SOQL sélective avant d’envoyer une requête au support.
Vous pouvez également déterminer quels champs peuvent être indexés en vous référant à Comment rendre une requête SOQL sélective et en effectuant une analyse de plan de requête dans la Developer Console, comme indiqué dans Outil de plan de requête.
L’application d’un index personnalisé aux valeurs de champ de case à cocher qui se produisent le moins fréquemment est l’approche la plus à même d’améliorer les performances et indique généralement une requête sélective.

Un index personnalisé ne peut pas être créé sur les types de champs suivants :

Listes de sélection multiple.
Champs de devise dans une organisation à devises multiples.
Champs de texte longs.
Champs binaires (champs de type blob, fichier ou texte chiffré).

Remarque : de nouveaux types de données, généralement complexes, peuvent être ajoutés à Salesforce et les champs de ces types peuvent ne pas autoriser l’indexation personnalisée.

En règle générale, un index personnalisé ne sera pas utilisé dans les cas suivants :

La ou les valeurs demandées dépassent le seuil défini par le système mentionné ci-dessus.
L’opérateur de filtre est un opérateur négatif tel que NOT EQUAL TO (ou ! =), NOT CONTAINS et NOT STARTS WITH.
L’opérateur CONTAINS est utilisé dans le filtre et le nombre de lignes à analyser est supérieur à 333 000. Cela est dû au fait que l’opérateur CONTAINS nécessite une analyse complète de l’index. Notez que ce seuil est sujet à changement.
En cas de comparaison avec une valeur vide (Name != ’’).

Remarque : il existe d’autres scénarios complexes dans lesquels les index personnalisés ne seront pas utilisés. Contactez votre représentant Salesforce si votre scénario n’est pas couvert par les cas mentionnés ou si vous avez besoin d’une assistance supplémentaire pour les requêtes non sélectives.

Exemples de requêtes SOQL sélectives

Afin de mieux comprendre si une requête pour un objet volumineux est sélective ou non, analysons quelques requêtes. Pour ces requêtes, nous supposerons qu’il existe plus de 200 000 enregistrements (y compris des enregistrements supprimés de manière réversible, c’est-à-dire des enregistrements supprimés qui sont toujours dans la corbeille) pour le sObject Compte (Account).

Requête 1 :

SELECT Id FROM Account WHERE Id IN (<liste d’ID de compte>)

La clause WHERE se trouve sur un champ indexé (ID). Si SELECT COUNT() FROM Account WHERE Id IN (<liste d’ID de compte>) renvoie moins d’enregistrements que le seuil de sélectivité, l’index sur ID est utilisé. Ce sera généralement le cas, car la liste des ID ne contient qu’un petit nombre d’enregistrements.

Requête 2 :

SELECT Id FROM Account WHERE Name != ’’

Étant donné que Compte est un objet volumineux même si Nom (Name) est indexé (clé primaire), ce filtre renvoie la plupart des enregistrements, rendant la requête non sélective.

Requête 3 :

SELECT Id FROM Account WHERE Name != ’’ AND CustomField__c = ’ValueA’

Ici, nous devons voir si chaque filtre, pris individuellement, est sélectif. Comme nous l’avons vu dans l’exemple précédent, le premier filtre n’est pas sélectif. Concentrons-nous donc sur le second. Si le nombre d’enregistrements renvoyés par SELECT COUNT() FROM Account WHERE CustomField__c = ’ValueA’ est inférieur au seuil de sélectivité et CustomField__c est indexé, la requête est sélective.

Requête 4 :

SELECT Id FROM Account WHERE FormulaField__c = ’ValueA’

Les règles suivantes doivent être vraies pour indexer un champ de formule :

La formule contient des champs provenant d’un seul objet (pas des champs de relation).
Le champ de formule ne fait référence à aucune fonction non déterministe (par exemple SYSDATE).
Le champ de formule ne fait référence à aucun champ non pris en charge à inclure dans les index. Cette liste n’est consignée à aucun endroit précis (il y a beaucoup de cas particuliers), mais dans la version Spring ’12 (176), createdById n’était pas pris en charge, alors qu’il l’était dans la version Summer ’12 (178). C’est également le cas pour CreatedDate.
Le champ de formule ne contient pas de références aux clés primaires (par exemple, ID)
Le champ de formule n’utilise pas la fonction TEXT(<champ de liste de sélection>)
Si la formule fait référence à des champs de recherche, l’option « Que faire si l’enregistrement de référence est supprimé ? » ne doit pas être définie sur « Effacer la valeur de ce champ » pour le champ.

Remarque : les performances de la requête SOQL seront analysées par le support Salesforce : si elle répond aux critères, l’indexation sera effectuée.