SI EXISTE antes de INSERTAR, ACTUALIZAR, ELIMINAR para la optimización

Eso no es útil para una sola actualización/eliminación/inserción.
Posiblemente agrega rendimiento si varios operadores después de la condición if.
En el último caso es mejor escribir

update a set .. where ..
if @@rowcount > 0 
begin
    ..
end

Usted no debe hacerlo para UPDATE y DELETE, como si hay impacto en el rendimiento, es no un positivo.

Para INSERT puede haber situaciones en las que su INSERT generará una excepción (UNIQUE CONSTRAINT violación, etc.), en cuyo caso es posible que desee evitarlo con el IF EXISTS y manejarlo con más gracia.

Ni

UPDATE … IF (@@ROWCOUNT = 0) INSERT

Ni

IF EXISTS(...) UPDATE ELSE INSERT

Los patrones funcionan como se espera bajo alta concurrencia. Ambos pueden fallar. Ambos pueden fallar con mucha frecuencia. MERGE es el rey-se sostiene mucho mejor.Hagamos algunas pruebas de estrés y veamos por nosotros mismos.

Aquí está la tabla que usaremos:

CREATE TABLE dbo.TwoINTs
    (
      ID INT NOT NULL PRIMARY KEY,
      i1 INT NOT NULL ,
      i2 INT NOT NULL ,
      version ROWVERSION
    ) ;
GO

INSERT  INTO dbo.TwoINTs
        ( ID, i1, i2 )
VALUES  ( 1, 0, 0 ) ;    

SI EXISTE (...) ENTONCES pattern frecuentemente falla bajo alta concurrencia.

Insertemos o actualicemos filas en un bucle usando la siguiente lógica simple: si una fila con el ID dado existe, actualícelo, y de lo contrario inserte uno nuevo. El siguiente bucle implementa esta lógica. Córtalo y pégalo en dos pestañas, cambia al modo texto en ambas pestañas y ejecútalo simultáneamente.

-- hit Ctrl+T to execute in text mode

SET NOCOUNT ON ;

DECLARE @ID INT ;

SET @ID = 0 ;
WHILE @ID > -100000
    BEGIN ;
        SET @ID = ( SELECT  MIN(ID)
                    FROM    dbo.TwoINTs
                  ) - 1 ;
        BEGIN TRY ;

            BEGIN TRANSACTION ;
            IF EXISTS ( SELECT  *
                        FROM    dbo.TwoINTs
                        WHERE   ID = @ID )
                BEGIN ;
                    UPDATE  dbo.TwoINTs
                    SET     i1 = 1
                    WHERE   ID = @ID ;
                END ;
            ELSE
                BEGIN ;
                    INSERT  INTO dbo.TwoINTs
                            ( ID, i1, i2 )
                    VALUES  ( @ID, 0, 0 ) ;
                END ;
            COMMIT ; 
        END TRY
        BEGIN CATCH ;
            ROLLBACK ; 
            SELECT  error_message() ;
        END CATCH ;
    END ; 

Cuando ejecutamos este script simultáneamente en dos pestañas, obtendremos inmediatamente una gran cantidad de violaciones de clave primaria en ambas pestañas. Esto demuestra lo poco fiable que es el patrón IF EXISTS cuando se ejecuta bajo alta concurrencia.

Nota: este ejemplo también demuestra que no es seguro usar SELECT MAX(ID)+1 o SELECT MIN(ID)-1 como el siguiente valor único disponible si lo hacemos bajo concurrencia.

No deberías hacer esto en la mayoría de los casos. Dependiendo de su nivel de transacción, ha creado una condición de carrera, ahora en su ejemplo aquí no importaría mucho, pero los datos se pueden cambiar desde la primera selección hasta la actualización. Y todo lo que has hecho es forzar SQL a hacer más trabajo

La mejor manera de saber con certeza es probar las dos diferencias y ver cuál le da el rendimiento adecuado.

IF EXISTS básicamente hará un SELECT-el mismo que UPDATE haría.

Como tal, disminuirá el rendimiento - si no hay nada que actualizar, hizo la misma cantidad de trabajo (ACTUALIZAR habría consultado la misma falta de filas que su selección) y si hay algo que actualizar, juet hizo una selección no necesaria.

El rendimiento de una declaración IF EXISTS:

IF EXISTS(SELECT 1 FROM mytable WHERE someColumn = someValue)

Depende de los índices presentes para satisfacer la consulta.

Hay un ligero efecto, ya que estás haciendo la misma comprobación dos veces, al menos en tu ejemplo:

IF EXISTS(SELECT 1 FROM Contacs WHERE [Type] = 1)

Tiene que consultar, ver si hay alguna, si es verdadera entonces:

UPDATE Contacs SET [Deleted] = 1 WHERE [Type] = 1

Tiene que consultar, ver cuáles...el mismo cheque dos veces sin ninguna razón. Ahora, si la condición que está buscando está indexada, debería ser rápida, pero para tablas grandes podría ver algún retraso solo porque está ejecutando la selección.

Esto repite en gran medida las anteriores (por tiempo) cinco (no, seis) (no, siete) respuestas, pero:

Sí, la estructura IF EXISTS que tiene duplicará el trabajo realizado por la base de datos. Si bien SI EXISTE se "detendrá" cuando encuentre la primera fila coincidente (no necesita encontrarlas todas), sigue siendo un esfuerzo adicional y en última instancia inútil for para actualizaciones y eliminaciones.

• Si no existe tal(s) fila (s), SI EXISTE, se realizará un análisis completo (tabla o índice) para determinar esto.
• Si una o más de estas filas existen, SI EXISTE leerá suficiente de la tabla/índice para encontrar la primera, y luego ACTUALIZAR o ELIMINAR volverá a leer la tabla para encontrarla de nuevo y procesarla -- y leerá "el resto" de la tabla para ver si hay más para procesar también. (Lo suficientemente rápido si está correctamente indexado, pero aún así.)

Así que de cualquier manera, terminarás leyendo toda la tabla o índice al menos una vez. Pero, ¿por qué molestarse con el SI EXISTE en primer lugar?

UPDATE Contacs SET [Deleted] = 1 WHERE [Type] = 1 

O la ELIMINACIÓN similar funcionará bien ya sea que se encuentren o no filas para procesar. Sin filas, tabla escaneada, nada modificado, ya está; 1 + filas, tabla escaneada, todo lo que debe ser modificado, hecho de nuevo. Una pasada, sin problemas, sin problemas, sin tener que preocuparse por "¿cambió la base de datos otro usuario entre mi primera consulta y mi segunda consulta".

INSERTAR es la situación en la que podría ser útil check comprobar si la fila está presente antes de añadirla, para evitar Violaciónes Claves Primarias o Únicas. Por supuesto, usted tiene que preocuparse por la concurrencia? ¿qué pasa si alguien más está tratando de añadir esta fila al mismo tiempo que usted? Envolver todo esto en un solo INSERTO de manejar todo en una transacción implícita (recuerde sus propiedades ÁCIDO!):

INSERT Contacs (col1, col2, etc) values (val1, val2, etc) where not exists (select 1 from Contacs where col1 = val1)
IF @@rowcount = 0 then <didn't insert, process accordingly>

Sí, esto afectará el rendimiento (el grado en que el rendimiento se verá afectado se verá afectado por una serie de factores). Efectivamente, está haciendo la misma consulta "dos veces" (en su ejemplo). Pregúntese si necesita o no estar a la defensiva en su consulta y en qué situaciones la fila no estaría allí? Además, con una instrucción update las filas afectadas es probablemente una mejor manera de determinar si algo se ha actualizado.

IF EXISTS....UPDATE

No lo hagas. Fuerza dos escaneos / búsquedas en lugar de uno.

Si update no encuentra una coincidencia en la cláusula WHERE, el costo de la instrucción update es solo un seek/scan.

Si encuentra una coincidencia, y si la precede w/ SI EXISTE, tiene que encontrar la misma coincidencia dos veces. Y en un entorno concurrente, lo que era cierto para el EXISTE puede no ser cierto por más tiempo para la ACTUALIZACIÓN.

Esta es precisamente la razón por la que las sentencias UPDATE/DELETE/INSERT permiten una cláusula WHERE. ¡Úsalo!

Si estás usando MySQL, entonces puedes usar insert ... en duplicado .