Apagado automático ...

MySQL

set autocommit=0;

Desactiva el autommit para la sesión actual.

Usted ejecuta su declaración, ver lo que ha cambiado, y luego revertir si está mal o confirmar si es lo que esperaba !

EDITAR: El beneficio de usar transacciones en lugar de ejecutar select query es que puede verificar el conjunto resultante con facilidad.

¿Qué pasa con las transacciones? Tienen la función de REVERSIÓN.

@ ver https://dev.mysql.com/doc/refman/5.0/en/commit.html

Por ejemplo:

START TRANSACTION;
SELECT * FROM nicetable WHERE somthing=1;
UPDATE nicetable SET nicefield='VALUE' WHERE somthing=1;
SELECT * FROM nicetable WHERE somthing=1; #check

COMMIT;
# or if you want to reset changes 
ROLLBACK;

SELECT * FROM nicetable WHERE somthing=1; #should be the old value

Respuesta a la pregunta de @rickozoe a continuación:

En general, estas líneas no se ejecutarán como una sola vez. En PHP f. e. escribirías algo así (quizás un poco más limpio, pero querías responder rápido ;-) ):

$MysqlConnection->query('START TRANSACTION;');
$erg = $MysqlConnection->query('UPDATE MyGuests SET lastname='Doe' WHERE id=2;');
if($erg)
    $MysqlConnection->query('COMMIT;');
else
    $MysqlConnection->query('ROLLBACK;');

Otra forma sería usar variables MySQL (ver https://dev.mysql.com/doc/refman/5.7/en/user-variables.htm l y https://stackoverflow.com/a/18499823/1416909 ):

# do some stuff that should be conditionally rollbacked later on

SET @v1 := UPDATE MyGuests SET lastname='Doe' WHERE id=2;
IF(v1 < 1) THEN
    ROLLBACK;
ELSE
    COMMIT;
END IF;

Pero sugeriría usar los envoltorios de lenguaje disponibles en su lenguaje de programación favorito.

Sé que esto es una repetición de otras respuestas, pero tiene algo de apoyo emocional para dar el paso adicional para probar la actualización: D

Para probar la actualización, hash # es tu amigo.

Si tiene una declaración de actualización como:

UPDATE 
wp_history
SET history_by="admin"
WHERE
history_ip LIKE '123%'

Se ACTUALIZA hash y se pone a prueba, luego hash de nuevo en:

SELECT * FROM
#UPDATE
wp_history
#SET history_by="admin"
WHERE
history_ip LIKE '123%'

Funciona para declaraciones simples.

Una solución adicional prácticamente obligatoria es, para obtener una copia (copia de seguridad duplicada), siempre que se utilice la actualización en una producción tabla. Phpmyadmin > operaciones > copiar: table_yearmonthday. Solo toma unos segundos para las tablas

No es una respuesta directa, pero he visto muchas situaciones de datos borked prod que podrían haberse evitado escribiendo la cláusula WHERE primero! A veces un WHERE 1 = 0 puede ayudar a armar una declaración de trabajo de manera segura también. Y mirar un plan de ejecución estimado, que estimará las filas afectadas, puede ser útil. Más allá de eso, en una transacción que revierte como otros han dicho.

Ejecute select query en la misma tabla con todas las condiciones where que está aplicando en update query.

Haz un SELECT de él,

Como si tuvieras

UPDATE users SET id=0 WHERE name='jan'

Convertirlo a

SELECT * FROM users WHERE name='jan'