ralentissement d'une requête SELECT avec des triggers en base [Résolu]

[nighthammer]

Bonjour,

J'ai un problème qui me parait assez suprenant. J'ai une base qui doit être compatible avec deux versions de mon application. Pour cela, j'ai mis des triggers en place afin de remplir les colonnes non remplies.

Le fonctionnement des triggers est bon puisque j'ai fait les vérifications en faisant des requêtes à la main. Mais je viens de me rendre compte que mes requêtes SELECT sont très lentes depuis que j'ai mis ces TRIGGERS. Cela me parait plus que surprenant étant donné que mes TRIGGERS se déclenchent sur les CREATE, UPDATE et DELETE.

Est ce que vous avez une idée pour investiguer là dessus ?

Voici un exemple de TRIGGER mis en place :

Code :

1
2
3
4
5
6
7
 
CREATE TRIGGER insertInMaTable AFTER INSERT ON MATABLE1
FOR EACH ROW BEGIN
	IF (NEW.COL1 <> 0) THEN
        INSERT INTO MATABLE2 VALUES (NEW.COL2, NEW.COL1);
    END IF;
END

Est ce que le fait que tous mes triggers soit en AFTER peut poser problème ?

Je nage... Un dernier truc, c'est que je travail avec hibernate pour accéder aux données, mais je doute que ce soit ça qui pose problème.

[SQLpro]

C'est normal. MySQL ne fonctionne pas de manière ensembliste et les déclencheurs doivent donc parcourir toutes les lignes une à une des données manipulées par votre ordre DML.
De plus les déclencheurs sont a l'intérieur de la transaction et allonge donc la durée du verrouillage de la table.
En sus les triggers MySQL sont de loin très peu performant, en sus d'être très limité dans leurs possibilité....$
A lire sur les limites (nombreuses) de MySQL : http://blog.developpez.com/sqlpro/p9...udre-aux-yeux/

De surcroit Hibernate est la pire plaie qui pouvait vous arriver, notamment en terme d'UPDATE. Ce gendre d'ORM ralentis jusqu'à 24 fois par rapport à un ordre SQL direct.
Pour vous en convaincre, lisez ceci : http://ormeter.net/images/stories/re...erformance.png
Regardez les performances du SINGLE UPDATE entre SQLclient et Hibernate. Le rapport est de 16 738 à 683, soit 24,47 fois moins rapide !
Lisez aussi ce que j'ai écrit sur le genre de catastrophe que provoque l'usage immodéré des ORM : http://img1.lemondeinformatique.fr/f...s-epaisses.pdf

A +

[nighthammer]

Merci de ta réponse.

Je ne pensais pas qu'il y avait autant de problèmes sur cette solution, surtout qu'elle est quand même très utilisée et par de très grosses sociétés qui ont des sites web avec beaucoup d'affluence.

Par contre, je n'ai pas trop le choix dans la solution à utiliser puisqu'elle est imposée, et donc je ne trouve pas vraiment de solution à mon problème. Est ce qu'il y a un problème dans la conception de mes triggers ?

Je n'ai peut être pas mis le meilleur exemple car c'est le cas le plus simple. En gros, je remplace une table d'association qui permettait d'avoir une relation n-n et une colonne dans une table pour avoir une relation 1-n. Du coup, pour ne pas avoir des triggers qui déclenchent des triggers, j'ai mis des conditions pour ne pas que ça boucle. Voici un exemple :

Code :

1
2
3
4
5
6
7
8
 
CREATE TRIGGER updateOnMaTable AFTER UPDATE ON MATABLE1
FOR EACH ROW
BEGIN
	IF ((SELECT COUNT(*) FROM MATABLE2 WHERE COL1=NEW.COL1 AND COL2=NEW.COL2)=0) THEN
        UPDATE MATABLE2 SET COL1=NEW.COL1 WHERE COL2=OLD.COL2 AND COL1=OLD.COL1;
    END IF;
END;

Est ce que vous voyez quelque chose de bizarre ?

Merci

[SQLpro]

Envoyé par nighthammer

Je ne pensais pas qu'il y avait autant de problèmes sur cette solution, surtout qu'elle est quand même très utilisée et par de très grosses sociétés qui ont des sites web avec beaucoup d'affluence.

ça c'est ce que raconte le marketing de MySQL..... Ce n'est pas ce que disent les benchmarks professionnels comme le TPC ou MySQL n'existe même pas !!!!
A lire : www.tpc.org

A +

[nighthammer]

J'ai trouvé.

La solution était bête, et je me suis laissé embarquer sur une mauvaise piste avant de regarder les principes de base. Il manquait juste un index sur ma nouvelle colonne ce qui ruinait les perfs.