select id, c.name as name
from a join b on a.id=b.id
join c on a.id=c.id
union
select id, d.name as name
from a join b on a.id=b.id
join d on a.id=d.id

Optimizado para

select id, 
       case when c.name is not null or c.name <> '' then c.name 
       else d.name end as name
from a join b on a.id=b.id
left join c on a.id=c.id
left join d on a.id=d.id
where c.name is not null or d.name is not null

El tiempo de respuesta de la consulta ha mejorado de 30 segundos a 13 segundos.

  • unión sql = 30 segundos
  • sql left join = 13secs

Sin embargo, al verificar el plan de consulta, la unión sql tiene un costo de E / S más bajo, vea a continuación:

  • sql union = Costo total de E / S estimado para el estado de cuenta 1 (en la línea 1): 6277566.
  • sql left join = Costo total de E / S estimado para el estado de cuenta 1 (en la línea 1): 10481124.

Estoy usando Sybase 12.5 ASE y el plan de consulta fue de DBArtisan 8.5; avíseme si necesito cargar todo el plan de consulta. Todavía no estoy muy familiarizado con los planes de consulta, pero hago optimizaciones de SQL aquí y allá, normalmente lo baso en las mejoras de tiempo. También verifiqué que el conjunto de resultados sea el mismo para ambas consultas (27949 filas). También enmascaré y simplifiqué los nombres de las tablas.

Mi pregunta es, ¿eso significa que la combinación izquierda de sql es más rápida pero requiere más recursos? Y si es así, ¿debería elegir la alternativa más rápida?

1
Carlos Jaime C. De Leon 8 feb. 2012 a las 06:55
Los planes de consulta a menudo se basan en estadísticas, mientras que la ejecución real de la consulta dependerá de los datos reales. ¿Están sus estadísticas actualizadas?
 – 
Joel Brown
8 feb. 2012 a las 07:41
¿Qué quieres decir con que las estadísticas están actualizadas? Ejecuté el plan de consulta hace un momento, los números de E / S que publiqué aquí son muy recientes.
 – 
Carlos Jaime C. De Leon
8 feb. 2012 a las 07:49
La base de datos recopila periódicamente estadísticas sobre las tablas (número de registros, etc.) y utiliza esas estadísticas para determinar el plan de consulta. Si sus estadísticas están desactualizadas, es posible que el plan no sea óptimo. Por ejemplo, si crea una nueva tabla e inserta una tonelada de datos y las estadísticas no se recopilan, la base de datos ejecutará la consulta como si la tabla estuviera vacía. Es probable que esto conduzca a un mal plan.
 – 
nolt2232
8 feb. 2012 a las 08:33

1 respuesta

La mejor respuesta

La base de datos realizará un almacenamiento en caché internamente, por lo que el tiempo de ejecución no siempre es el mejor indicador. Si ejecuta la primera consulta y luego ejecuta la segunda inmediatamente después, la segunda tiene una ventaja injusta porque es probable que algunos de los datos se almacenen en caché.

Como todas las preguntas de ajuste de bases de datos, nada está escrito en piedra. Personalmente, me gusta la unión porque creo que es un poco más legible, pero estrictamente desde una perspectiva de rendimiento, haría algunas pruebas extendidas durante un período de tiempo más largo (para minimizar la influencia del almacenamiento en caché) y ver cómo funcionan.

¿Cuántos datos hay en estas tablas? ¿Tiene índices en las columnas de identificación en las cuatro tablas? Si no, eso acelerará su consulta más cualquier cambio en el sql.

2
nolt2232 8 feb. 2012 a las 07:53