Gran diferencia, TABLOCK intentará obtener bloqueos "compartidos" y TABLOCKX candados exclusivos.
Si está en una transacción y obtiene un bloqueo exclusivo en una tabla, EG:
SELECT 1 FROM TABLE WITH (TABLOCKX)
Ningún otro proceso podrá tomar cualquier cerraduras en la mesa, lo que significa todos las consultas que intenten comunicarse con la mesa se bloquearán hasta que se confirme la transacción.
TABLOCK solo toma un bloqueo compartido, los bloqueos compartidos se liberan después de que se ejecuta una declaración si el aislamiento de su transacción es READ COMMITTED (defecto). Si su nivel de aislamiento es mayor, por ejemplo:SERIALIZABLE , los bloqueos compartidos se mantienen hasta el final de una transacción.
Los bloqueos compartidos son, hmmm, compartidos. Lo que significa que 2 transacciones pueden leer datos de la tabla al mismo tiempo si ambas tienen un bloqueo S o IS en la tabla (a través de TABLOCK ). Sin embargo, si transaction A tiene un bloqueo compartido en una tabla, transaction B no podrá tomar un candado exclusivo hasta que se liberen todos los candados compartidos. Lea acerca de qué bloqueos son compatibles con cuáles en msdn.
Ambas sugerencias hacen que la base de datos omita la adopción de bloqueos más granulares (como bloqueos de nivel de fila o página). En principio, los bloqueos más granulares le permiten una mejor concurrencia. Entonces, por ejemplo, una transacción podría estar actualizando la fila 100 en su tabla y otra fila 1000, al mismo tiempo a partir de dos transacciones (se complica con los bloqueos de página, pero omitámoslo).
En general, lo que desea son bloqueos granulares, pero a veces es posible que desee reducir la concurrencia de db para aumentar el rendimiento de una operación en particular y eliminar la posibilidad de interbloqueos.
En general, no usaría TABLOCK o TABLOCKX a menos que lo necesite absolutamente para algún caso extremo.
