Per semplicità, i trigger sono la strada da percorrere per implementare qualsiasi tipo di tracciamento delle modifiche al database. Tuttavia, è necessario essere consapevoli di ciò che accade sotto il cofano quando si utilizzano i trigger.
Secondo MySQL Stored Procedure Programming , la pagina 256 sotto la voce "Trigger Overhead" dice quanto segue:
È importante ricordare che, per necessità, i trigger generano un sovraccarico dell'istruzione DML a cui si applicano. la quantità effettiva di overhead dipenderà dalla natura del trigger, ma --- poiché tutti i trigger MySQL vengono eseguiti PER OGNI FILA --- l'overhead può accumularsi rapidamente per le istruzioni che elaborano un numero elevato di righe. Dovresti quindi evitare di inserire costose istruzioni SQL o codici procedurali nei trigger.
Una spiegazione estesa del sovraccarico del trigger è riportata alle pagine 529-531. Il punto di conclusione di quella sezione indica quanto segue:
La lezione qui è questa: poiché il codice trigger verrà eseguito una volta per ogni riga interessata da un'istruzione DML, il trigger può facilmente diventare il fattore più significativo nelle prestazioni DML. Il codice all'interno del corpo del trigger deve essere il più leggero possibile e, in particolare, qualsiasi istruzione SQL nel trigger deve essere supportata da indici ogni volta che è possibile.
Non menzionato nel libro è un altro fattore quando si usano i trigger: quando si tratta della registrazione di controllo, si prega di essere consapevoli di ciò in cui si accedono i dati. Dico questo perché se dovessi scegliere di accedere a una tabella MyISAM, ogni INSERT in una tabella MyISAM produce un blocco completo della tabella durante INSERT. Questo può diventare un serio collo di bottiglia in un ambiente ad alto traffico e transazioni elevate. Inoltre, se il trigger si trova su una tabella InnoDB e si registrano le modifiche in MyISAM dall'interno del trigger, ciò disabiliterà segretamente la conformità ACID (ovvero, ridurrà le transazioni di blocco al comportamento di autocommit), che non può essere ripristinato.
Quando si usano i trigger su tabelle InnoDB e si registrano le modifiche
- La tabella a cui accedi è anche InnoDB
- L'autocommit è disattivato
- Configura a fondo i blocchi INIZIA TRANSAZIONE ... COMMIT / ROLLBACK
In questo modo, i registri di controllo possono beneficiare di COMMIT / ROLLBACK come le tabelle principali.
Per quanto riguarda l'utilizzo delle stored procedure, è necessario chiamare scrupolosamente la stored procedure in ogni punto del DML rispetto alla tabella da tracciare. Si potrebbero facilmente perdere le modifiche alla registrazione di fronte a decine di migliaia di righe di codice dell'applicazione. Inserire tale codice in un trigger elimina la ricerca di tutte quelle istruzioni DML.
AVVERTIMENTO
A seconda della complessità del trigger, può comunque essere un collo di bottiglia. Se si desidera ridurre i colli di bottiglia nella registrazione di controllo, è possibile fare qualcosa. Tuttavia, richiederà un piccolo cambiamento di infrastruttura.
Utilizzando l'hardware delle materie prime, creare altri due server DB
Questo servirà a ridurre l'I / O di scrittura sul database principale (MD) a causa della registrazione di controllo. Ecco come puoi realizzarlo:
Passaggio 01) Attiva la registrazione binaria nel database principale.
Passaggio 02) Utilizzando un server economico, configurare MySQL (stessa versione di MD) con la registrazione binaria abilitata. Questo sarà DM. Replica dell'installazione da MD a DM.
Passaggio 03) Utilizzando un secondo server economico, configurare MySQL (stessa versione di MD) con la registrazione binaria disabilitata. Imposta ogni tabella di controllo per usare --replicate-do-table . Questo sarà AU. Replica dell'installazione da DM a AU.
Step 04) mysqldump le strutture della tabella da MD e caricale in DM e AU.
Passaggio 05) Convertire tutte le tabelle di controllo in MD per utilizzare il motore di archiviazione BLACKHOLE
Passaggio 06) Convertire tutte le tabelle in DM e AU per utilizzare il motore di archiviazione BLACKHOLE
Passaggio 07) Convertire tutte le tabelle di controllo in AU per utilizzare il motore di archiviazione MyISAM
Quando fatto
- DM replicherà da MD e registrerà le cose solo nel suo registro binario
- Con il filtro --replicate-do-table su tutte le tabelle di controllo, AU si replicherà da DM
Ciò che fa è archiviare le informazioni di controllo su un server DB separato e ridurre anche qualsiasi degrado di I / O in scrittura che MD avrebbe normalmente.