Los resultados finales serán en realidad una consulta mucho más compleja, teniendo uno a muchos parámetros y la cadena construida y ejecutada utilizando sp_executesql
Creo que, al menos, necesita el sintaxis completa FROM, JOIN y WHERE; de lo contrario, su consulta real puede encontrar información (por ejemplo, agregando un INNER JOIN que no estaba en la consulta original IF EXISTS y resulta que no está satisfecho).
Si va a tener ese problema, es posible que desee obtener los PK en una especie de "Tabla de retención de ID de lote" para que pueda simplemente hacer referencia a los PK para la segunda parte de "Presentación" de su consulta.
¿Qué piensas hacer si obtienes 376,986 resultados? Si se los va a mostrar al usuario en la pantalla, con algún tipo de paginación, entonces tener los resultados en una "Tabla de retención de ID de lote" podría ayudar con eso (aunque, obviamente, cualquier adición/eliminación, etc. a los datos de usuario) ensuciará la pantalla paginada).
Alternativamente, si va a utilizar paginación solo use TOP/LIMIT/SET ROWCOUNT para restringir los resultados a la primera página llena (asegúrese de tener un ORDER BY para que la secuencia sea repetible), y luego resuelva qué hacer para la página 2 cuando el usuario presiona el botón NEXT-PAGE (abordamos eso con el botón NEXT-PAGE que contiene la PK del último registro visualizado, en orden de clasificación, para que la página siguiente pueda reanudarse desde ese punto en adelante))
El Optimizador de consultas hará diferentes cosas dependiendo de la lista SELECT, por lo que preguntar "SI EXISTE" seguido de "SELECCIONAR Col1, COl2, ... DESDE ..." puede significar que ejecuta el completo consulta dos veces, de manera diferente, utilizando diferentes datos almacenados en caché y planes de consulta, por lo que en general puede suponer una mayor tensión para el servidor y hacer que los usuarios esperen más tiempo que solo obtener la primera página/100 filas, etc.
SQL El servidor guardará en caché el plan de consulta para sp_ExecuteSQL, pero asegúrese de parametrizar la consulta para que el plan guardado en caché se reevalúe siempre que sea posible
Esto depende del optimizador de consultas del DBMS. Si sus pruebas muestran que lleva 4 segundos con IF EXISTS y COUNT, entonces IF EXISTS probablemente no está optimizado. –
Por ahora los resultados son los mismos, pero estaba preguntando más por el futuro. A medida que aumentaba el número de filas, me preguntaba si el rendimiento del recuento sería más lento. Alguien sugirió que no lo haría, ya que las tablas se analizan y el recuento de actuaciones sigue siendo bastante rápido de todos modos. Estoy tendiendo hacia el IF EXISTE más y más. – Robert
Compararía ambos, con caché limpia, comprobación de duración, CPU y lecturas a través del Analizador de SQL, y esperaría que EXISTS no solo se desempeñara mejor en SQL Server, sino que también escalara mejor cuando crecieran los volúmenes de datos. Con pequeñas cantidades de datos, no habrá mucha diferencia, pero la escalabilidad es importante. – AdaTheDev