SKIP LOCKED es una cláusula de SQL, típicamente utilizada en conjunto con sentencias SELECT ... FOR UPDATE o SELECT ... FOR SHARE, que modifica el comportamiento de bloqueo de una transacción. En lugar de esperar a que se liberen los bloqueos sobre las filas que cumplen los criterios de la consulta, o de fallar la consulta si se encuentra un bloqueo, SKIP LOCKED instruye al motor de la base de datos a simplemente omitir esas filas bloqueadas y continuar procesando las filas disponibles. Esto es particularmente útil en escenarios donde múltiples procesos o workers compiten por un conjunto de recursos o tareas, y la disponibilidad inmediata es preferible a la consistencia estricta de un conjunto de resultados completo en un instante dado.
Esta funcionalidad se encuentra implementada en sistemas de gestión de bases de datos relacionales (RDBMS) modernos. Por ejemplo, PostgreSQL introdujo SKIP LOCKED en la versión 9.5, y Oracle Database lo ha soportado durante mucho tiempo. MySQL también ofrece una funcionalidad similar. Su aplicación más común es en la implementación de "work queues" o sistemas de procesamiento de tareas distribuidas. Un pool de workers puede ejecutar repetidamente una consulta como `SELECT * FROM tasks WHERE status = 'pending' ORDER BY created_at ASC FOR UPDATE SKIP LOCKED LIMIT 1;` para obtener la siguiente tarea disponible, bloquearla, procesarla y luego actualizar su estado, sin bloquearse mutuamente al intentar acceder a la misma tarea pendiente.
Para un Arquitecto de Sistemas, SKIP LOCKED es una herramienta estratégica para diseñar sistemas de procesamiento de tareas de alta concurrencia y baja latencia. Permite desacoplar la lógica de negocio de la gestión explícita de bloqueos y reintentos, simplificando el código del worker. El principal trade-off es que la consulta con SKIP LOCKED no garantiza un conjunto de resultados determinista; las filas omitidas podrían haber sido relevantes para una lógica de negocio que esperara un conjunto completo. Sin embargo, para "work queues" donde el orden estricto no es crítico o puede ser manejado a nivel de aplicación (ej. re-encolando tareas fallidas), la ganancia en rendimiento y resiliencia frente a la contención de bloqueos es significativa. Es crucial entender que, si bien reduce la contención, no elimina la necesidad de transacciones ACID para garantizar la integridad de la tarea seleccionada y su posterior actualización.