¿Qué es más rápido, EXISTE antes o después del INSERT?

Question

Tengo un SP en SQL Server que se ejecuta cientos de veces por minuto y necesita verificar el tráfico entrante en una base de datos. Por el momento se hace lo siguiente

INSERT INTO table 
SELECT @value1,@value2 WHERE NOT EXISTS 
(SELECT * FROM table WHERE value1 = @value1 AND value2 = @value2); 

Sin embargo, yo también podría ir con

IF NOT EXISTS(SELECT * FROM table WHERE value1 = @value1 AND value2 = @value2)  
    INSERT INTO table (value1,value2) VALUES (@value1,@value2); 

Lo que sería más rápido? Me da la sensación de que no hay mucha diferencia entre ellos, pero históricamente no soy muy bueno en TSQL ... =/

ACTUALIZACIÓN: Whoops ... significa que el EXISTS usa más de 1 valor para encontrar si un existe registro, por lo que una restricción única no funcionará. Editó la muestra para reflejar que ...

Answer 1

Después de la adición de un tropecientos comentarios sobre esta pregunta y sus respuestas, voy a tener mi propia ir en contestarla.

yo no esperaría ninguna diferencia importante en el rendimiento entre los dos propuestos propuesto en la pregunta original. Por un lado, como señaló Ray, el segundo enfoque podría evitarle hacer algunos preparativos para el inserto, pero, por otro lado, un RDBMS generalmente funciona mejor con las instrucciones de lote, como en la primera solución.

KM y DVK sugieren agregar una restricción UNIQUE, lo que hará que la prueba de exclusividad sea implícita, pero requerirá que agregue algún tipo de manejo de errores alrededor de su declaración INSERT. Me es difícil ver por qué esto debería agregar un rendimiento adicional, suponiendo que ya tiene un índice que cubre las dos columnas. Si no tiene dicho índice, agréguelo y reconsidere su necesidad de más rendimiento.

Si el control de la unicidad se realiza explícita o implícita no debería importar que yo sepa.Si se gana algo haciendo que la verificación se realice "dentro" del estómago del DBMS, esa ganancia podría ser consumida por la sobrecarga asociada con los errores de elevación y manejo cuando existen duplicados.

---

El resultado final: Suponiendo un índice ya está en su lugar, si usted todavía se encuentra lusting para el rendimiento, mi recomendación es que realice pruebas empíricas sobre las tres soluciones sugeridas. Prepare un pequeño programa que simule los datos de entrada esperados y elimine cada una de las tres soluciones con unos pocos miles de millones de filas, incluida una cantidad plausible de duplicados. hacer esto, asegúrese de publicar sus resultados :-)

Answer 2

Si desea que los valores sean únicos, ¿por qué no simplemente crear una restricción única en el valor, hacer un INSERTO sin SELECCIONAR y manejar correctamente el error de violación de restricción?

Eso sería más rápido que cualquiera de estos enfoques.

Además, su primer enfoque no funciona - por el momento de llegar a seleccionar, ya insertó el valor de modo de seleccionar, obviamente, encontrar lo que acaba de insertar.

Answer 3

Si tuviera que adivinar, yo supongo que la segunda opción sería más rápido. El servidor sql no tendría que hacer ningún tipo de configuración para la inserción si la existente falla, mientras que en la primera, podría buscar algunos nombres de tablas y campos y prepararse para una inserción que nunca ocurre. Sin embargo, lo probaría en el analizador de consultas y vería lo que dice el plan.

Answer 4

simplemente lo hacen, e ignorar cualquier error (supone una restricción única en valor) ...

BEGIN TRY 
    INSERT INTO Table (value) VALUES (@value); 
END TRY 
BEGIN CATCH 
    PRINT 'it was already in there!' 
END CATCH 

Desde este corre cientos de veces por minuto, sugerencias de bloqueo, debe añadirse a los selecciona y una transacción a avoid a race condition

(SELECT * FROM Table WITH (UPDLOCK, HOLDLOCK) WHERE value = @value); 

sin embargo, mi idea propuesta de basta con insertar y hacer caso omiso de cualquier error de restricción duplicado evitaría una condición de carrera también.

Answer 5

En un entorno casi simultánea, concurrente INSERT puede suceder en el medio IF NOT EXISTS y INSERT en su segunda consulta.

Su primera consulta colocará los bloqueos compartidos en el registro que examina, que no se levantará hasta el final de la consulta, por lo que será imposible insertar un nuevo registro hasta que se ejecute la consulta.

Sin embargo, no debe confiar únicamente en este comportamiento. Coloque una restricción adicional UNIQUE en el value.

No solo hará que la base de datos sea más uniforme, sino que creará un índice que hará que la primera consulta sea más rápida.

Answer 6

Ambas variantes son incorrectas. Deberá insertar pares de duplicados @ value1, @ value2, garantizados.

La forma correcta de manejar esto es para hacer cumplir una restricción única en dos columnas e insertar siempre y manejar la violación de restricción:

ALTER TABLE Table ADD CONSTRAINT uniqueValue1Value UNIQUE (value1, values2); 

e insertar:

BEGIN TRY 
    INSERT INTO Table (value1, value2) VALUES (@value1, @value2); 
END TRY 
BEGIN CATCH 
    DECLARE @error_number int, @error_message NVARCHAR(4000), @xact_state INT; 
    SET @error_number = ERROR_NUMBER(); 
    SET @error_message = ERROR_MESSAGE(); 
    SET @xact_state = XACT_STATE(); 
    IF (@xact_state = -1) 
    BEGIN 
    ROLLBACK TRANSACTION; 
    END 
    IF (@error_number != 2627) /* 2627 is ' Cannot insert duplicate key in object ...' */ 
    BEGIN 
     RAISERROR(N'Error inserting into Table: %i %s', 16,1, @errror_number, @error_message); 
    END 
ENd CATCH 

Mientras estos pueden parecer complicados, uno tiene que tener en cuenta un pequeño detalle llamado corrección. Esto es mucho más simple si se compara con una solución basada en pistas de bloqueo. Esta es también la solución más eficaz: solo busca uno. Todas las demás soluciones necesitan al menos dos búsquedas (una para validar que se puede insertar, una para insertar).