Vamos por parte:
- Los problemas de concurrencia en MySQL se resuelven principalmente usando transacciones, para lo cual se requiere el uso de tablas InnoDB. Ese es el modo eficiente de hacerlo, ya que el bloqueo, como lo planteas, te traerá otros problemas de ejecución, que no has considerado.
- Realizar un bloqueo de tabla no es necesariamente la mejor opción, porque esto no impide que los otros usuarios accedan a leerla. Lo único que no pueden hacer es
escribir en ella. Con esto, puede suceder que otro usuario genere una clave posible que sea exactamente la misma, sin saberlo, porque la consistencia en tu proyecto la estás manejando a nivel de script.
- Por otro lado, la elección de claves autoincrementales en sistemas de alta concurrencia, especialmente para tablas críticas como usuarios, clientes, productos, etc, puede no ser una buena idea. Antes bien, es conveniente usar identificadores tales que seguramente no puedan duplicarse (CUIT/RUT a nivel impositivo, Códigos de Barra para los productos), y usar
esos valores como claves primarias. Tales valores generarían un error de inserción aún si no usas transacciones.
- La gestión de la próxima clave es un tema ya resuelto, no hay que inventar el agujero del mate. Pero tienes que tomarte el tiempo de leer el manual de referencia oficial de MySQL, que es donde aparece eso (
Bloqueo de la próxima clave: El problema del fantasma).
- Finalmente, es mejor que latas de este tipo se realicen por medio de stored procedures, porque de ese modo se pueden modularizar en ellos las validaciones que deben hacerse,
aun cuando las hayas hecho anteriormente, y como se ejecutan como un sólo llamado, puedes asegurar la integridad de datos de mejor forma.
Dale una leída a este link, para entender lo que son las transacciones y cómo operan, si no conoces el tema:
http://ict.udlap.mx/people/carlos/is341/bases10.html