UNION sur des BD de même structure

Bonjour,

D'habitude, avec une petite recherche et la consultation de quelques articles, je trouve assez rapidement des pistes pour résoudre mes problèmes, mais là, je ne comprends vraiment pas... :calim2:

J'ai 4 bases de données, de structure quasi-identique parce qu'il s'agit des bases de données sur lesquelles travaille un logiciel de production unique (même si nous avons 4 instances du logiciel parce que 4 activités différentes donc 4 paramétrages différents... enfin je peux pas trop rentrer dans le détail, mais l'idée est là ^^).

Pour un atelier, j'ai besoin de données extraites des 4 bases (ALU, PVC, VB, VR).

J'avais donc jusqu'à la semaine dernière une vue faisant l'UNION de 4 sous-requêtes pratiquement identiques, et qui s'exécutait en quelques secondes.
Cette semaine, la vue a décidé de ne plus rendre service, et nous offre en dédommagement des expirations de délai.

On l'a donc partagée en 4 vues différentes, pour faire l'UNION sur une cinquième, pour identifier le problème.

Chacune des vues met entre 1 et 4 secondes à renvoyer un résultat, ce qui est correct, nos serveurs étant complètement saturés en ce moment...

Mais tout se complique quand on recommence à faire des UNION ou même des UNION ALL... :?

En effet, si l'on concatène les résultats des deux premières vues, ALU et PVC, tout va bien : 1 seconde. Idem pour les deux autres vues, VB et VR.

Mais dès qu'on mixe ces deux "groupes", avec une union de ALU et VB, par exemple, on a l'impression de lui parler chinois, et une exécution super lente commence : un affichage laborieux par blocs de 256 lignes, et une attente de plus de 3 minutes !

On a essayé de trouver des différences dans les types des champs, mais rien n'y fait, impossible de comprendre ce qui différencie ALU et PVC de VB et VR, sachant que ces 4 bases sont utilisées par la même appli, et ont été créées de la même façon...

Si vous avez des pistes de recherche, je suis preneuse... :oops:

J'espère que mes explications confuses vous paraîtront claires; j'ai essayé de vous donner un maximum d'informations pour comprendre...

Dans l'attente de petits indices...

Bon appétit !

Merci d'avoir pris le temps de lire.

Delphine :)

Bonjour,

Y a t'il eu un chargement de données important dans vos bases ?
Vos index sont ils correctement défragmentés ? Vos statistiques à jour ?
Y a t'il des transactions posant des verrous sur vos bases et plus particulièrement sur les tables sources utilisées ?

Bonne journée

Les flux de données dans nos bases sont les mêmes que ceux que l'on observe tous les jours; rien de particulier à signaler.

Nos index ? euh... joker ? :oops:
Je ne sais pas exactement comment ça marche, mais il y a les mêmes dans les 4 bases puisqu'ils sont définis par l'éditeur du logiciel, et on ne s'en occupe jamais, donc ça n'expliquerait pas la différence de performance... si ?

Nos statistiques ? Alors là, je n'ai carrément aucune idée de ce que c'est...

Concernant les verrous, je ne sais pas si ça répond à la question, mais en voyant la chute des performances hier en arrivant, j'ai rajouté des WITH (NOLOCK) partout immédiatement en pensant que je bloquais tout, mais sans succès...


La seule différence a priori qu'il y ait entre ALU/PVC et VB/VR est que ALU et PVC ont été créées il y a longtemps avec la version SQL Server 2000, puis on a upgradé le server pour passer sur du 2005, et alors seulement on a étendu notre activité et ajouté les bases VB et VR.
Je ne sais pas si cette différence de version à la création peut avoir une influence... Mais ça n'expliquerait encore pas pourquoi d'un seul coup la vue qui fonctionnait correctement la semaine dernière est devenue inexploitable...

En tous cas, merci d'essayer de me donner des pistes... :)

Bonne après-midi, et je prends volontiers d'autres idées ! ^^

Citation:

---

Envoyé par tiamat249

Je ne sais pas exactement comment ça marche, mais il y a les mêmes dans les 4 bases puisqu'ils sont définis par l'éditeur du logiciel, et on ne s'en occupe jamais, donc ça n'expliquerait pas la différence de performance... si ?

---

Les index doivent être régulièrement reorganisés ou recréer afin de garantir de bonnes performances. (Sur les tables sujettes à des modifications de données)
Vérifiez si vous avez un job mis en place qui s'occupe de cette tache de manière automatique.
Si pas, songez à en mettre un en place, tournant dans les heures de charge creuses de vos serveurs.
Je ne sais pas si d'un jour à l'autre les performances peuvent être radicalement différentes à cause de cela, néanmoins c'est une bonne pratique qui aidera d'une facon ou d'une autre à obtenir de meilleures performances.

Citation:

---

Envoyé par tiamat249

Nos statistiques ? Alors là, je n'ai carrément aucune idée de ce que c'est...

---

Les statistiques sont utiles à l'optimisateur de requêtes pour choisir le meilleur plan d'exécution d'un ordre SQL.
Voyez : sp_updatestats dans la documentation pour mettre celles-ci à jour.

Citation:

---

Envoyé par tiamat249

Concernant les verrous, je ne sais pas si ça répond à la question, mais en voyant la chute des performances hier en arrivant, j'ai rajouté des WITH (NOLOCK) partout immédiatement en pensant que je bloquais tout, mais sans succès...

---

Voyez si d'autres process que les votres posent des verrous sur les objets.

Citation:

---

Envoyé par tiamat249

La seule différence a priori qu'il y ait entre ALU/PVC et VB/VR est que ALU et PVC ont été créées il y a longtemps avec la version SQL Server 2000, puis on a upgradé le server pour passer sur du 2005, et alors seulement on a étendu notre activité et ajouté les bases VB et VR.
Je ne sais pas si cette différence de version à la création peut avoir une influence... Mais ça n'expliquerait encore pas pourquoi d'un seul coup la vue qui fonctionnait correctement la semaine dernière est devenue inexploitable...

---

A priori non.

Citation:

---

Envoyé par tiamat249

En tous cas, merci d'essayer de me donner des pistes... :)

---

De rien

Citation:

---

Envoyé par tiamat249

Bonne après-midi, et je prends volontiers d'autres idées ! ^^

---

Jetez un oeil au plan d'exécution de vos requètes, ca peut vous fournir des informations utiles à la résolution de votre problème.

Bonjour,

Citation:

---

même si nous avons 4 instances du logiciel parce que 4 activités différentes donc 4 paramétrages différents

---

Ce n'est pas une raison suffisante pour avoir 4 bases de données, qui engendrent la maintenance d'au moins 8 fichiers de base de données, et peut-être des écritures supplémentaires sur disque.
Vous auriez du à la place utiliser une colonne qui serve de discriminant dans les tables où cela est nécessaire.
Imaginez que demain votre entreprise décide d'augmenter ses activités en transformant une centaine de matériaux ... pas sûr que vous parviendrez à maintenir 100 bases de données pour y refaire par exemple le même traitement sur chacune d'entre-elles ;)

En tous cas je rejoins les propos de Pti_Dje concernant les index et les statistiques.
Quelles sont les options des bases de données pour le ré-échantillonnage des statistiques (pour faire simple, elles renseignent sur la sélectivité des valeurs dans les colonnes, c'est à dire les valeurs et leur nombre d'occurrence dans une colonne) ?

Code:

---

1 2 3 4 5

SELECT is_auto_create_stats_on , is_auto_update_stats_on , is_auto_update_stats_async_on FROM sys.databases WHERE name = 'maBD'

---

Quel est la taille de vos bases de données ?

Vous pouvez utiliser la requête suivante pour voir quand les statistiques ont été mises à jour pour la dernière fois :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

SELECT T.name AS nom_table , S.name AS nom_statistique , I.name AS nom_index , C.name AS nom_colonne , STATS_DATE(S.object_id, S.stats_id) AS derniere_MAJ , S.auto_created , S.user_created FROM sys.tables AS T INNER JOIN sys.stats AS S ON T.object_id = S.object_id INNER JOIN sys.stats_columns AS SC ON S.object_id = SC.object_id AND S.stats_id = SC.stats_id INNER JOIN sys.columns AS C ON SC.object_id = C.object_id AND SC.column_id = C.column_id LEFT JOIN sys.indexes AS I ON S.object_id = I.object_id AND S.stats_id = I.index_id ORDER BY T.name

---

La colonne nom_index ne prend de valeur que si la statistique correspond à celle d'un index.
La colonne derniere_MAJ vous renseignera sur la dernière fois que les statistiques ont été mises à jour pour une colonne.
Cela ne signifie pas directement qu'elles sont obsolètes si la colonne est rarement mise à jour.

Pour voir l'état de vos indexes, il vous faut considérer leur fragmentation.
Je vous laisse vous amuser avec les deux vues suivantes :

Code:

---

1 2	FROM sys.indexes IDX JOIN sys.dm_db_index_physical_stats

---

Regardez les colonnes avg_fragmentation_in_percent, avg_page_space_used_in_percent, page_count de la vue sys.dm_db_index_physical_stats.
Pour un faible nombre de pages pas d'inquiétude sur le pourcentage de fragmentation.
En revanche Microsoft recommande d'avoir au plus 30% de fragmentation sur les tables volumineuses.

@++ ;)

Citation:

---

Envoyé par Ptit_Dje

c'est une bonne pratique qui aidera d'une facon ou d'une autre à obtenir de meilleures performances.

---

J'en parlerai à mon chef : lui saura mieux me dire ce qui est mis en place et ce qui "réfléchit" la nuit.

Citation:

---

Envoyé par Ptit_Dje

Les statistiques sont utiles à l'optimisateur de requêtes pour choisir le meilleur plan d'exécution d'un ordre SQL.
Voyez : sp_updatestats dans la documentation pour mettre celles-ci à jour.

---

Je ne sais pas s'il prendra le temps de s'occuper des index, mais si une "simple" mise à jour peut faire gagner en performance, il y a des chances pour qu'il m'accorde quelques minutes d'attention !

Citation:

---

Envoyé par Ptit_Dje

Voyez si d'autres process que les votres posent des verrous sur les objets.

---

A priori aucun.

Citation:

---

Envoyé par Ptit_Dje

Jetez un oeil au plan d'exécution de vos requètes, ca peut vous fournir des informations utiles à la résolution de votre problème.

---

C'est ce qu'on a fait hier après-midi, mais apparemment rien n'en ressort et mon collègue en a déduit qu'il fallait juste ne plus faire l'UNION, et plutôt fournir 4 jeux de données aux utilisateurs...
C'est une autre façon de régler les problèmes...

Donc merci, je vais essayer de leur donner ces informations.
J'espère qu'ils en tiendront compte : un "petit" problème sur une petite vue, ca cache probablement d'autres problèmes...

Citation:

---

Envoyé par elsuket

Bonjour,
Ce n'est pas une raison suffisante pour avoir 4 bases de données. [...]
Vous auriez du à la place utiliser une colonne qui serve de discriminant dans les tables où cela est nécessaire.
Imaginez que demain votre entreprise décide d'augmenter ses activités en transformant une centaine de matériaux ...

---

Malheureusement, nous n'avons pas développé le logiciel de production que nous utilisons tous les jours, et l'éditeur a visiblement estimé qu'il valait mieux créer plusieurs bases de données plutôt que de modifier son code pour prendre en compte les différentes activités...
En revanche, nous produisons des menuiseries en ALU et en PVC, et des Volets Roulants et Battants : les modes de production sont complètement différents, mais l'activité est suffisamment spécifique (et aujourd'hui suffisamment étendue) pour que le risque de la voir se développer comme vous le décrivez soit négligeable...

Citation:

---

Envoyé par elsuket

En tous cas je rejoins les propos de Pti_Dje concernant les index et les statistiques.[...]

Je vous laisse vous amuser avec les deux vues suivantes :

Code:

---

1 2	FROM sys.indexes IDX JOIN sys.dm_db_index_physical_stats

---

Regardez les colonnes avg_fragmentation_in_percent, avg_page_space_used_in_percent, page_count de la vue sys.dm_db_index_physical_stats.

---

Bon ben voilà mes devoirs de la semaine ^^
Ca tombe bien, j'avais prévu de m'ennuyer !

Plus sérieusement, merci pour toutes ces informations, je vais tout de suite commencer à regarder comment ça marche et ce qu'on trouve comme informations...

Comme je l'ai dit dans mon post précédent, mes collègues ont estimé que fournir 4 vues réglait le problème puisque l'utilisateur récupérait toutes ses données, et ça supprimait le problème de performances...

Pour moi, l'affaire n'est pas réglée puisque le problème a été contourné et non réglé, et je pense qu'avec les outils que vous m'avez fournis, c'est sur un gain de performance général, qu'on peut travailler, et non sur simplement la résolution de ce mystère (je n'ai toujours pas compris pourquoi du jour au lendemain, certaines unions sont réalisées dans la seconde alors que les autres flinguent complètement le système!).

Donc encore merci pour ces éléments de recherche : je vais creuser, et quand j'aurai trouvé ce qui bloquait, je vous tiendrai au courant !

Merci à tous les deux, et bonne journée !

Citation:

---

je n'ai toujours pas compris pourquoi du jour au lendemain, certaines unions sont réalisées dans la seconde alors que les autres flinguent complètement le système!

---

L'optimiseur de requêtes de SQL Server est basé sur les coûts, c'est à dire qu'il va rechercher la façon de résoudre la requête qu'on lui soumet en consommant le moins de ressources, c'est à dire, pour faire très simple, en lisant le moins de pages de données possible.

Supposons que vous ayez une table qui contient un million de lignes.
Cette table est mise à jour une fois par semaine le lundi, mais ses statistiques ne sont jamais mises à jour.

L'optimiseur de requêtes ne peut donc pas savoir que les données ont changé.
Donc il va continuer à utiliser la méthode de résolution de la requête, appelée plan de requête, que vous avez soumis la première fois que vous avez exécuté la requête, et qui est sauvé en RAM.

Si au moment où vous avez exécuté la requête pour la première fois, en filtrant une des colonnes sur la valeur 100 par exemple, et qu'à ce moment là la colonne contenait peu de lignes avec cette valeur, alors l'optimiseur aura choisi un index qui lui permettre de résoudre la requête très vite.

Si 3 semaines plus tard votre colonne ne contient quasiment que la valeur 100, alors ce plan de requête est "faux", d'où l'importance de la mise à jour des statistiques.

La mise à jour automatique des statistiques peut avoir été désactivée car elle génère une consommation de ressources conséquente, et il faut alors réaliser celle-ci "manuellement", avec un plan de maintenance et/ou un job, aux heures de faible utilisation de la base de données ;).

Je vous conseille de lire "Pro SQL Server 2008 Query Performance Tuning Distilled" publié par APress, vous y apprendrez probablement beaucoup de choses ;)

@++ ;)

Citation:

---

Envoyé par elsuket

Vous pouvez utiliser la requête suivante pour voir quand les statistiques ont été mises à jour pour la dernière fois. [...]

---

Apparemment, sur les tables qui sont amenées à bouger en permanence, je trouve en derniereMAJ des dates qui me rassurent. Donc bien qu'on ne s'en occupe pas, des routines mises en place par l'éditeur doivent le faire...

Citation:

---

Envoyé par elsuket

Quelles sont les options des bases de données pour le ré-échantillonnage des statistiques (pour faire simple, elles renseignent sur la sélectivité des valeurs dans les colonnes, c'est à dire les valeurs et leur nombre d'occurrence dans une colonne) ?

Code:

---

1 2 3

SELECT is_auto_create_stats_on, is_auto_update_stats_on, is_auto_update_stats_async_on FROM sys.databases WHERE name = 'maBD'

---

---

Là, je trouve pour les 4 bases les deux premières valeurs à 1 et la dernière à 0. J'en déduis que c'est mieux que si c'était pire ! ^^

Citation:

---

Envoyé par elsuket

Quel est la taille de vos bases de données ?

---

http://imagik.fr/uploads/215634


Prochaine étape, les infos sur la fragmentation... mais j'étudierai la question cette après-midi !

Bon appétit ! :)

Citation:

---

Donc bien qu'on ne s'en occupe pas, des routines mises en place par l'éditeur doivent le faire...

---

Je parie plus sur les options de bases de données que révèlent la requête pour laquelle vous avez écrit :

Citation:

---

Là, je trouve pour les 4 bases les deux premières valeurs à 1 et la dernière à 0.

---

Faites attention aux accroissements en pourcents, surtout si les bases de données commencent à faire quelques GB.
Un jour où l'autre vous allez ralentir les accès parce que vous attendrez après un accroissement du fichier...
Préférez plutôt un nombre de MB, par exemple 128 ...
Le mieux aurait été néanmoins de les dimensionner dès les départ, ce que je ne suggère pas les tailles actuelles de vos fichiers ;).

@++ ;)

1) vous ne nous avez pas montré les requêtes en cause... Préfixez vous les tables en jeu par leur schéma SQL ? Si n on faites le.
2) vous pouvez demander à ce que les lectures se passent sans verrous en faisant soit un TRANSACTION ISOLATION LEVELE READ UNCOMMITTED préalable, soit en plaçant le tag NOLOCK après le nom de table dans une clause WITH.
3) enfin vous devez faire un UNION ALL sinon UNION dé-doublonne, ce qui peut être problématique sur de très grosses tables.

A +

Citation:

---

Envoyé par SQLpro

1) vous ne nous avez pas montré les requêtes en cause... Préfixez vous les tables en jeu par leur schéma SQL ? Si n on faites le.

---

Alors je veux bien vous donner une des 4 sous-requêtes, mais vous ne serez pas beaucoup avancé, je pense... Ca ne servira qu'à vous rendre compte du gros bazard avec lequel on travaille... :)

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

SELECT TOP (100) PERCENT SUBSTRING(IND.dbo.EPV.NUM_SER, 1, 1) AS Type, SUBSTRING(IND.dbo.EPV.REF_CMD, 3, 12) AS COMMANDE, Chacal21.dbo.tbl_Projet.tReference1 AS CHANTIER, IND.dbo.EPV.COD_ANA, IND.dbo.EPV.COD_CLT, IND.dbo.CLT.NOM, IND.dbo.CLT.TEL, IND.dbo.CLT.TLC, IND.dbo.CLT.ADR_1, IND.dbo.CLT.ADR_2, IND.dbo.CLT.ADR_3, IND.dbo.CLT.COD_PST, IND.dbo.CLT.VIL, IND.dbo.EPV.DAT_PIE, IND.dbo.EPV.CMT, Chacal21.dbo.tbl_Projet.NBCHASSIS, Chacal21.dbo.tbl_Projet.dDateCreation, Chacal21.dbo.tbl_Projet.DATE_VALIDATION, Chacal21.dbo.V3_tDivers_All.tDivers1, Chacal21.dbo.V3_tDivers_All.tDivers6, Chacal21.dbo.tbl_Projet.FLAG_LANCEE_DATE, Chacal21.dbo.tbl_Projet.FLAG_TERMINEE_DATE, Chacal21.dbo.tbl_Projet.NOM_COUL, Chacal21.dbo.V3_tDivers_All.tDivers5, Chacal21.dbo.C1_C_ATELIERS.Nom_Chacal AS ATELIERS, Chacal21.dbo.tbl_Projet.DATE_DER_VAL, Chacal21.dbo.V3_tDivers_All.tDivers11, Chacal21.dbo.tbl_Projet.FLAG_ANNULATION, Chacal21.dbo.tbl_Projet.FLAG_ANNULATION_DATE FROM Chacal21.dbo.C1_C_ATELIERS WITH (NOLOCK) INNER JOIN IND.dbo.EPV WITH (NOLOCK) INNER JOIN IND.dbo.CLT WITH (NOLOCK) ON IND.dbo.EPV.COD_CLT = IND.dbo.CLT.COD_CLT INNER JOIN Chacal21.dbo.tbl_Projet WITH (NOLOCK) ON SUBSTRING(IND.dbo.EPV.REF_CMD, 3, 12) COLLATE French_CI_AI = Chacal21.dbo.tbl_Projet.tNomProjet ON Chacal21.dbo.C1_C_ATELIERS.IdSite = Chacal21.dbo.tbl_Projet.PtrIdSiteProduction LEFT OUTER JOIN Chacal21.dbo.V3_tDivers_All WITH (NOLOCK) ON Chacal21.dbo.tbl_Projet.IdProjet = Chacal21.dbo.V3_tDivers_All.IdProjet WHERE (IND.dbo.EPV.DAT_PIE >= YEAR(CURRENT_TIMESTAMP - 120) * 10000 + MONTH(CURRENT_TIMESTAMP - 120) * 100 + DAY(CURRENT_TIMESTAMP - 120)) AND (IND.dbo.EPV.TYP_PIE IN ('CO', 'BL', 'FA')) AND (SUBSTRING(IND.dbo.EPV.NUM_SER, 1, 1) = 'A') AND (IND.dbo.EPV.FLG_MAJ <> 'S') AND (IND.dbo.EPV.COD_STT <> 'XX')

---

Assez exceptionnel compte tenu de la nature de nos tables, il n'y a AUCUN schéma de bases de données. Je me bats pour en imposer sur les bases que je crée pour de nouvelles applications, mais là, il n'y a rien, alors que c'est notre logiciel de production et donc notre base de données centrale, et la plus lourde.
De toutes façons, quand on essaye de reconstituer les relations entre les tables, on se rend compte qu'il vaut mieux qu'elles ne soient visibles nulle part tellement la base est mal faite (avoir besoin de 8 jointures pour récupérer le nombre de lignes d'accessoires d'une commande et le commercial qui en est responsable me paraît "un peu" lourd...). Et je ne parle pas des informations redondantes et parfois non cohérentes...

Citation:

---

Envoyé par SQLpro

2) vous pouvez demander à ce que les lectures se passent sans verrous en faisant soit un TRANSACTION ISOLATION LEVELE READ UNCOMMITTED préalable, soit en plaçant le tag NOLOCK après le nom de table dans une clause WITH.

---

J'avais opté pour le WITH(NOLOCK) mais je n'ai jamais entendu parler de l'instruction précédente... en quoi consiste-t-elle ? Et quelles différences dans le fonctionnement ?

Citation:

---

Envoyé par SQLpro

3) enfin vous devez faire un UNION ALL sinon UNION dé-doublonne, ce qui peut être problématique sur de très grosses tables.

---

Longtemps il n'y a eu que des UNION dans les vues, mais j'essaye petit à petit de les remplacer par des UNION ALL, ce qui n'a pas suffit à résoudre le problème de lenteur...

Merci en tous cas d'avoir pris le temps de répondre.
(Je prendrai volontiers une petite explication sur les différences entre WITH(NOLOCK) et l'instruction proposée en alternative. A défaut je chercherai à l'occasion, mais les explications sont souvent floues pour moi...)

Bonne fin de matinée !

Remplacez :

Code:

---

AND (SUBSTRING(IND.dbo.EPV.NUM_SER, 1, 1) = 'A')

---

par

Code:

---

AND (IND.dbo.EPV.NUM_SER LIKE 'A%')

---

D'autre part, le fait de faire des jointures sur des SUBSTRING(IND.dbo.EPV.REF_CMD, 3, 12) est particulièrement mauvais :
1) vous ne respectez pas la première forme normale
2) aucun index n'est activable.

Remplacez ceci par une colonne calculée indexée :

Code:

---

1 2 3 4

ALTER IND.dbo.EPV.REF_CMD ADD COMMANDE AS SUBSTRING(IND.dbo.EPV.REF_CMD, 3, 12) PERSISTED;   CREATE INDEX X_123456789 ON IND.dbo.EPV.REF_CMD (COMMANDE);

---

Et remplacez partout l'appel de ce substring, par cette colonne calculée.

A +

Citation:

---

Envoyé par SQLpro

Remplacez : [SUBSTRING = 'A' par REF_CMD LIKE 'A%']

---

Je pensais qu'un = était moins coûteux qu'un LIKE mais je vais faire le remplacement tout de suite. Merci pour la correction !

Par contre, pour ce qui est de la colonne calculée indexée, je ne pourrai pas la rajouter. Je peste régulièrement contre l'absence de cette colonne (qui nous indique "juste" dans laquelle des 4 bases on doit chercher les commandes) mais je ne peux rajouter aucun champ dans les tables de ces bases de données...
Interdiction formelle de toucher à la structure des tables dans les bases de données du logiciel de production et de celui de la compta !

Enfin je vais essayer de prendre votre conseil comme un argument à l'attention de mes chefs, mais je doute qu'ils reviennent sur cette règle...

Encore merci, et bonne fin de journée ! :)

Citation:

---

e pensais qu'un = était moins coûteux qu'un LIKE mais je vais faire le remplacement tout de suite. Merci pour la correction !

---

L'optimiseur de requêtes de base sur les statistiques de répartition des valeurs dans les colonnes.

Pour une colonne de type chaîne de caractères, il sait donc par quelle lettre commence celles-ci, ce qui vous permet de bénéficier d'un index sur cette colonne (vous n'en bénéficierez pas si vous écrivez LIKE '%a' ou LIKE '%a%').

En revanche, comme le moteur de base de données ne peut pas maintenir de statistiques sur toutes les lettres de toutes les chaînes d'une colonne, vous ne pouvez pas bénéficier d'un index lorsque vous utilisez la fonction SUBSTRING(), car ce n'est pas SARGable.

LIKE est un prédicat, SUBSTRING() une fonction.
Le fait d'utiliser une fonction sur une colonne ne permet jamais de profiter d'un index, sauf si comme vous le conseille SQLPro, vous ajoutez une colonne calculée persistante indexée à votre table ;)

@++ ;)