Discussion :

[vinse51]

Bonjour,

Je suis en train de mettre en place des triggers destinés à maintenir des compteurs, par exemple un trigger qui va incrémenter un champ [nb_messages] d'une table [forum_sujet] lorsqu'un nouveau message est inséré dans une table [forum_message].

Par exemple j'ai un trigger de la sorte sur la table [forum_message] :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
UPDATE forum_sujet SET nb_messages = nb_messages + 1
FROM inserted i WHERE id = i.sujet_id

Jusque là tout va bien mais je viens de me rendre compte grâce au plan d'exécution que peu importe si l'enregistrement existe ou pas dans la table [forum_sujet], l'instruction "Clustered Index Update" sur cette table est quand même exécutée (avec un "actual number of rows" = 0) et prend 40% du coût de la requête !

J'ai bien pensé utiliser une instruction IF EXISTS mais ce n'est pas possible car non ensembliste.

Y-a-t-il un moyen de ne pas exécuter l'update si la ligne n'existe pas, mais d'une manière ensembliste ?

Merci d'avance pour vos réponses.

[iberserk]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
UPDATE F
SET F.nb_messages = F.nb_messages + I.nbr
FROM forum_sujet F 
   INNER JOIN (SELECT sujet_id,COUNT(*)  as nbr
                    FROM inserted 
                    GROUP BY sujet_id) I
   ON I.sujet_id=F.ID

[vinse51]

Bonjour et merci pour cette réponse.

En fait ce code optimise effectivement ma requête dans le sens où s'il y a plusieurs messages du même sujet inséré en même temps le compteur ne sera mis à jour qu'une seule fois. C'est donc une optimisation en effet indispensable.

Par contre cela ne résout pas mon problème initial, à savoir que peu importe le fait qu'il y ait ou pas une correspondance de ligne dans la jointure, il y a toujours un "Clustered Index Update" qui s'exécute et c'est ça que je ne comprend pas.

Pourquoi le moteur effectue cette exécution alors qu'il n'y a pas de ligne à mettre à jour et pour quelle raison cela a un coût ?
Y-a-t-il un verrou de posé sur la table même si le nombre de ligne à mettre à jour est égal à 0 ?

[SQLpro]

Quelle que soit la manière d'aborder la chose il faut d'abord lire les données, même si c'est pour ne rien mettre à jour ! C'est pourquoi votre UPDATE coute de la lecture même si aucune ligne n'est mise à jour.

La seule chose qui pourra améliorer l'ensemble est de voir s'il y a un index adéquat... La solution d'berseek, n'améliorera pas les choses... Elle risque même d'être plus couteuse...

A +

[vinse51]

Je suis d'accord le moteur doit impérativement lire les données en premier pour effectuer une éventuelle mise à jour.

Mais ce n'est pas cette lecture qui me pose problème mais plutôt l'instruction update qui intervient après la lecture, une fois que le moteur sait qu'il n'y a pas de ligne à mettre à jour.

Je ne pense pas que cette instruction ne fasse d'entrées/sorties par contre elle a un coût processeur non négligeable et je ne comprends pas pourquoi le moteur n'arrête pas l'instruction lorsqu'il sait qu'il n'y a pas de ligne à mettre à jour.

[SQLpro]

Je pense que vous vous méprenez sur la compréhension de ce qu'est un plan de requête. C'est une estimation... pas la vérité. La vérité sera l'exécution...

A +

[vinse51]

Hum effectivement cela pourrait être l'explication.

Mais pourtant j'ai bien inclus le "plan d’exécution réel".
Est-ce que même le plan réel ne représente pas forcément la réalité de l'exécution ?