Solución:
Un par de advertencias que me gustaría señalar al usar LAST_INSERT_ID
:
-
Sé que mencionaste inserciones de una sola fila. Pero al hacer inserciones de varias filas,
LAST_INSERT_ID()
devolverá el valor de la primera fila insertada (no la última). -
Si el inserto falló,
LAST_INSERT_ID()
sería indefinido. Lo mismo ocurre con las reversiones automáticas de transacciones (debido a errores). -
Si realiza una inserción en una transacción que se realiza correctamente y aún emite una
ROLLBACK
,LAST_INSERT_ID()
se dejaría como estaba antes de la reversión. -
Hay un par de advertencias al usar
AUTO_INCREMENT
yLAST_INSERT_ID
en la replicación basada en declaraciones. El primero es cuando se usa en un disparador o función. El segundo es el escenario menos común donde su columna auto_increment es parte de una clave primaria compuesta y no es la primera columna de la clave.
Para ampliar más el punto número 2 en la respuesta dada por DTest:
En las versiones de MySQL que he usado, es una buena idea explicidad restablezca el valor de LAST_INSERT_ID antes de cada bloque de código donde planea realizar una inserción.
Esto se puede hacer así:
-- initialize the LAST_INSERT_ID to some flag value:
SELECT LAST_INSERT_ID( some_flag_init_value_of_your_choice );
-- perform the insert
INSERT INTO ttt (ccc) VALUES (vvv);
-- retrieve the id of the inserted row:
SELECT LAST_INSERT_ID();
Después de que se ejecute la serie de declaraciones anterior, sabrá si la inserción tuvo algún efecto al verificar si LAST_INSERT_ID todavía estaba establecido en “some_flag_init_value_of_your_choice” al final de la ejecución.
De lo contrario, puede terminar con la siguiente situación problemática:
INSERT INTO ttt ( ccc ) VALUES ( 'a' ); -- assume this succeeds.
SELECT LAST_INSERT_ID(); -- this will return the unique id of the new row with value 'a'.
INSERT INTO ttt ( ccc ) VALUES ( 'b' ); -- assume this FAILS.
SELECT LAST_INSERT_ID(); -- this will STILL RETURN the unique id of the row with 'a'.
Porque el segundo inserto tiene fallido, es posible que haya esperado que la segunda llamada a LAST_INSERT_ID devuelva NULL o que produzca un conjunto de resultados vacío (cero filas). El hecho de que todavía devuelva un identificador de número entero válido puede inducirle a error al pensar que la segunda inserción FUE EXITOSA cuando no lo hizo.
Las cosas se ponen AÚN MÁS EXTRAÑAS cuando considera que LAST_INSERT_ID continuará conservando y repitiendo la última identificación única exitosa incluso si las siguientes declaraciones de inserción fallidas están dirigidas diferentes mesas que la tabla que produjo la última identificación única exitosa. En otras palabras, inserta en la tabla TA y obtiene una identificación de 5, luego inserta en TB (pero falla), pero todavía ve un 5. Basado en eso, usted pensar que acaba de crear una nueva fila en TA con id de 5 y una nueva fila en TB con id de 5, mientras que en realidad no existe ninguna fila en TB con id 5, o existe una fila de este tipo, pero en realidad no tiene nada que ver con ningún código que acaba de ejecutar.