Mysql
 sql >> Base de données >  >> RDS >> Mysql

Récupération après une mauvaise requête de mise à jour MySQL ?

Il y a deux leçons à tirer ici :

  1. Données de sauvegarde
  2. Effectuer des instructions UPDATE/DELETE dans une transaction, afin de pouvoir utiliser ROLLBACK si les choses ne se passent pas comme prévu

Connaître la gestion des transactions (autocommit, explicite et implicite) pour votre base de données peut vous éviter d'avoir à restaurer les données à partir d'une sauvegarde.

Les transactions contrôlent les instructions de manipulation des données pour s'assurer qu'elles sont atomiques. Être "atomique" signifie que la transaction se produit ou non. La seule façon de signaler l'achèvement de la transaction à la base de données est d'utiliser soit un COMMIT ou ROLLBACK déclaration (selon ANSI-92, qui malheureusement n'incluait pas la syntaxe pour créer/débuter une transaction, elle est donc spécifique au fournisseur). COMMIT applique les modifications (le cas échéant) apportées à la transaction. ROLLBACK ne tient pas compte des actions qui ont eu lieu dans la transaction - hautement souhaitable lorsqu'une instruction UPDATE/DELETE fait quelque chose d'involontaire .

En règle générale, les instructions DML (Insert, Update, Delete) individuelles sont exécutées dans une transaction de validation automatique - elles sont validées dès que l'instruction se termine avec succès. Ce qui signifie qu'il n'y a aucune possibilité de restaurer la base de données à l'état antérieur à l'exécution de l'instruction dans des cas comme le vôtre. En cas de problème, la seule option de restauration disponible consiste à reconstruire les données à partir d'une sauvegarde (à condition qu'il en existe une). Dans MySQL, autocommit est sur par défaut pour InnoDB - MyISAM ne prend pas en charge les transactions. Il peut être désactivé en utilisant :

SET autocommit = 0

Une transaction explicite est lorsque les instructions sont enveloppées dans un bloc de code de transaction explicitement défini - pour MySQL, c'est START TRANSACTION . Il nécessite également un COMMIT explicitement créé ou ROLLBACK déclaration à la fin de la transaction. Les transactions imbriquées sortent du cadre de cette rubrique.

Les transactions implicites sont légèrement différentes des transactions explicites. Les transactions implicites ne nécessitent pas de définir explicitement une transaction. Cependant, comme les transactions explicites, elles nécessitent un COMMIT ou ROLLBACK déclaration à fournir.

Conclusion

Les transactions explicites sont la solution la plus idéale - elles nécessitent une instruction, COMMIT ou ROLLBACK , pour finaliser la transaction, et ce qui se passe est clairement indiqué pour que les autres puissent le lire en cas de besoin. Les transactions implicites sont acceptables si vous travaillez avec la base de données de manière interactive, mais COMMIT les déclarations ne doivent être spécifiées qu'une fois que les résultats ont été testés et déterminés comme étant valides.

Cela signifie que vous devez utiliser :

SET autocommit = 0;

START TRANSACTION;
  UPDATE ...;

...et n'utilisez que COMMIT; lorsque les résultats sont corrects.

Cela dit, les instructions UPDATE et DELETE ne renvoient généralement que le nombre de lignes affectées, pas des détails spécifiques. Convertissez ces instructions en instructions SELECT et examinez les résultats pour vous assurer de leur exactitude avant à tenter l'instruction UPDATE/DELETE.

Avenant

Les instructions DDL (Data Definition Language) sont automatiquement validées - elles ne nécessitent pas d'instruction COMMIT. IE :table, index, procédure stockée, base de données et instructions de création ou de modification de vue.