2011-03-22 16 views
5

Tengo dos consultas, llamémosles de consultas A y B. ConsultaUNION o UNION ALL en dos sentencias de selección hace que sean muy lento

Ambas consultas ejecutadas en menos de un segundo para el escenario estoy las pruebas y Query A arrojan 1 resultado, y Query B devuelve 0 resultados.

Si unió (o unió todas) estas dos consultas, se tarda más de un minuto en devolver el resultado (esperado) 1.

Ambas consultas seleccionan las mismas columnas de las mismas tablas. Podría reescribir todo esto sin una unión mediante una cláusula where altamente condicional, pero estaba tratando de alejarme de hacer eso.

¿Alguna idea? No estoy seguro de qué parte de la consulta y el esquema exactos puedo compartir sin compartir, pero me complace proporcionar lo que puedo.

Esto está en MSSQL 2008 si es importante para la respuesta de alguien.

+0

puede usted Repita el resultado comenzando con un nuevo esquema vacío y agregando un pequeño número de tablas que contengan solo datos de prueba que no sean confidenciales. No tiene que ser datos de su aplicación, solo números aleatorios o una base de datos de muestra (o datos del volcado de datos de StackOverflow, o lo que realmente quiera). –

+0

La base de datos en cuestión solía ejecutarse en 2005 hasta hace poco, y tuve una copia (con los mismos datos) todavía ejecutándose en un servidor de 2005. La consulta completa (incluida la unión) se ejecuta como se esperaba sin gastos adicionales. ¿Hay algo específico que haya cambiado desde 2005 -> 2008 que cause esto de lo que todos sepan? – Jay

+0

Pude replicar en un servidor 2008 diferente. Me sale el problema allí, independientemente del nivel de compatibilidad. No pensé que eso ayudaría, pero pensé que valía la pena intentarlo. – Jay

Respuesta

1

Me gustaría intentar ver los planes de ejecución dentro de Management Studio para las consultas individuales, y luego comparar eso con el plan de ejecución para la consulta que contiene el UNION.

Si existe una diferencia drástica en los tiempos de ejecución, me imagino que hay algo mal con el plan de ejecución para la consulta de UNION. Identificar lo diferente le ayudará a usted (y quizás a nosotros) en la dirección correcta sobre cuál es el problema subyacente.

0

¿Están ambos haciendo escaneos de tabla? Parece que puede exceder la capacidad de caché y está almacenando en caché en disco.

Incluso si son de la misma tabla, los registros probablemente se bloquearían de forma independiente.

1

Las cláusulas separadas en un UNIÓN que son muy similares y en las mismas tablas se pueden combinar en una consulta por el optimizador. Puede ver esto por la falta en el operador de UNIÓN en el plan de consulta. He visto cosas similares antes, pero rara vez

Lo que puede hacer es una SELECT.. INTO #temp... para la primera consulta seguido de un INSERT #temp... para la segunda

Ahora, ¿de dónde leí esto ...