Eh bien, ce n'est pas sûr, d'après Manuel Mysql :
Cette option envoie une instruction START TRANSACTIONSQL au serveur avant de vider les données. Il n'est utile qu'avec des tables transactionnelles telles que InnoDB et BDB, car il vide alors l'état cohérent de la base de données au moment où BEGIN a été émis sans bloquer aucune application.
Lorsque vous utilisez cette option, vous devez garder à l'esprit que seules les tables InnoDB sont vidées dans un état cohérent. Par exemple, toute table MyISAM ou MEMORY vidé lors de l'utilisation de cette option peut toujours changer d'état.
Lorsqu'un --single-transaction dump est en cours, pour garantir un fichier de vidage valide (contenu correct de la table et coordonnées du journal binaire), aucune autre connexion ne doit utiliser les instructions suivantes :ALTER TABLE, CREATE TABLE, DROP TABLE, RENAME TABLE, TRUNCATETABLE. Une lecture cohérente n'est pas isolée de ces instructions, donc leur utilisation sur une table à vider peut entraîner le SELECT effectué par mysqldump pour récupérer le contenu de la table afin d'obtenir un contenu incorrect ou échouer.
L'option --single-transaction et l'option --lock-tables s'excluent mutuellement car LOCK TABLES entraîne la validation implicite de toutes les transactions en attente.
Cette option n'est pas prise en charge pour les tables MySQLCluster; la cohérence des résultats ne peut pas être garantie du fait que le moteur de stockage NDBCLUSTER ne prend en charge que le niveau d'isolement de la transaction READ_COMMITTED. Vous devez toujours utiliser NDBbackup et restaurer à la place.
Pour vider de grandes tables, vous devez combiner l'option --single-transaction avec --quick.
Si vous souhaitez sauvegarder/déplacer votre base de données en direct, vous devez envisager Réplication MySQL
