Dans un souci de simplicité, les déclencheurs sont la voie à suivre pour implémenter tout type de suivi des modifications de la base de données. Cependant, vous devez être conscient de ce qui se passe sous le capot lorsque vous utilisez des déclencheurs.
Selon MySQL Stored Procedure Programming , la page 256 sous la rubrique "Trigger Overhead" dit ce qui suit:
Il est important de se rappeler que, par nécessité, les déclencheurs ajoutent une surcharge à l'instruction DML à laquelle ils s'appliquent. la quantité réelle de surcharge dépendra de la nature du déclencheur, mais --- comme tous les déclencheurs MySQL s'exécutent POUR CHAQUE RANG --- la surcharge peut rapidement s'accumuler pour les instructions qui traitent un grand nombre de lignes. Vous devez donc éviter de placer des instructions SQL ou du code procédural coûteux dans les déclencheurs.
Une explication détaillée de la surcharge de déclenchement est donnée aux pages 529-531. Le point de conclusion de cette section indique ce qui suit:
La leçon à tirer est la suivante: étant donné que le code de déclenchement s'exécutera une fois pour chaque ligne affectée par une instruction DML, le déclencheur peut facilement devenir le facteur le plus important des performances DML. Le code à l'intérieur du corps du déclencheur doit être aussi léger que possible et - en particulier - toutes les instructions SQL dans le déclencheur doivent être prises en charge par des index chaque fois que possible.
Non mentionné dans le livre est un autre facteur lors de l'utilisation de déclencheurs: en ce qui concerne la journalisation d'audit, veuillez être conscient de ce dans quoi vous vous connectez. Je dis cela parce que si vous choisissez de vous connecter à une table MyISAM, chaque INSERT dans une table MyISAM produit un verrou de table complet pendant l'insertion. Cela peut devenir un goulot d'étranglement sérieux dans un environnement à trafic élevé et à transactions élevées. De plus, si le déclencheur est contre une table InnoDB et que vous enregistrez les modifications dans MyISAM à partir du déclencheur, cela désactivera secrètement la conformité ACID (c'est-à-dire, réduira les transactions de bloc au comportement de validation automatique), qui ne peut pas être annulée.
Lors de l'utilisation de déclencheurs sur des tables InnoDB et des modifications de journalisation
- La table à laquelle vous vous connectez est également InnoDB
- Vous avez désactivé la validation automatique
- Vous configurez soigneusement les blocs START TRANSACTION ... COMMIT / ROLLBACK
De cette façon, les journaux d'audit peuvent bénéficier de COMMIT / ROLLBACK comme les tables principales.
En ce qui concerne l'utilisation des procédures stockées, vous devrez appeler minutieusement la procédure stockée à chaque point de DML par rapport à la table en cours de suivi. On pourrait facilement manquer des changements de journalisation face à des dizaines de milliers de lignes de code d'application. Placer un tel code dans un déclencheur élimine la recherche de toutes ces instructions DML.
CAVEAT
Selon la complexité du déclencheur, il peut toujours s'agir d'un goulot d'étranglement. Si vous souhaitez réduire les goulots d'étranglement dans la journalisation d'audit, vous pouvez faire quelque chose. Cependant, cela nécessitera un petit changement d'infrastructure.
En utilisant du matériel standard, créez deux autres serveurs DB
Cela servira à réduire les E / S d'écriture sur la base de données principale (MD) en raison de la journalisation d'audit. Voici comment vous pouvez y parvenir:
Étape 01) Activez la journalisation binaire dans la base de données principale.
Étape 02) À l'aide d'un serveur peu coûteux, configurez MySQL (même version que MD) avec la journalisation binaire activée. Ce sera DM. Configurez la réplication de MD vers DM.
Étape 03) À l'aide d'un deuxième serveur peu coûteux, configurez MySQL (même version que MD) avec la journalisation binaire désactivée. Configurez chaque table d'audit pour utiliser --replicate-do-table . Ce sera AU. Configurez la réplication de DM vers AU.
Étape 04) mysqldump les structures de table de MD et chargez-les dans DM et AU.
Étape 05) Convertissez toutes les tables d'audit dans MD pour utiliser le moteur de stockage BLACKHOLE
Étape 06) Convertissez toutes les tables en DM et AU pour utiliser le moteur de stockage BLACKHOLE
Étape 07) Convertissez toutes les tables d'audit en AU pour utiliser le moteur de stockage MyISAM
Lorsque vous avez terminé
- DM répliquera à partir du MD et enregistrera les éléments dans son journal binaire uniquement
- Avec le filtre --replicate-do-table sur toutes les tables d'audit, AU répliquera à partir de DM
Cela permet de stocker les informations d'audit sur un serveur de base de données distinct et de réduire également toute dégradation des E / S d'écriture que MD aurait normalement.