plan de ejecución estimado

03/02/2006 - 21:21 por Miquel | Informe spam

Hola,

Tengo una tabla (Articulos) con unos 150.000 registros, que entre otros
campos contiene
strArtículo nvarchar,
intCodigoEspecialidad int,
intAño int

y otra tabla (Especialidades), con unos 20 registros:
intCodigoEspecialidad int,
strEspecialidad nvarchar

El usuario desea encontar un artículo mediante su texto y la consulta es del
tipo

create procedure buscaArticulo (@Art nvarchar(..), @CodiEspecialidad = null)
as
select strArticulo from articulo inner join especialidades on
articulos.intCodigoEspecialidad = especialidades.intCodigoEspecialidad where
strArículo like @art + '%' and (@CodigoEspecialidad is null or
intCodigoEspecialidad = @CodigoEspecialidad)

Pues bien.
Con los índices que tenia antes, el plan de ejecución hacia un HASH MATCH/
RIGHT OUTER JOIN entre las dos tablas con CLUSTERED INDEX SCAN para las dos,
y con unos costos de 50% y 67%
Al crear los indices que recomienda el asistente para índices, el plan de
ejecución hace MERGE JOIN /RIGHT OUTER JOIN tambien sobre las dos tablas y
con CLUSTERED INDEX SCAN pero sus costos son de 75% y 100%.

Son comparables los costos si se refieren a HASH MATCH/ RIGHT OUTER JOIN o
a MERGE JOIN /RIGHT OUTER JOIN ?
O sea cual sea la operación, un costo del 75% es siempre mayor que uno del
50%?

Grácias

Siga el debate

6 respuestas

Tengo una respuesta

Preguntas similare

Mostrar todos los temas similares

Leer las respuestas

#6 Miquel

07/02/2006 - 22:37 | Informe spam

Hola,
Si. Estoy leyendo "The definitive Guide to SQL Server Performance
Optimization", de Don Jones, y algo así había entendido también.
Nunca me habia parado mucho a pensar como de eficiente eran mis consultas
(con que el usuario lo viera rápido, ya me bastaba). Pero ahora, a
medida que voy "aprendiendo", la verdad es que me resulta fascinante.
Claro que ahora tardo un poco más ;-)

Muchas grácias

"Gustavo Larriera [MVP]" escribió en el mensaje
news:%

Desde el punto de vista téorico, la respuesta que brindan los Books Online
dice:

"
Merge join itself is very fast, but it can be an expensive choice if sort
operations are required. However, if the data volume is large and the
desired data can be obtained presorted from existing B-tree indexes, merge
join is often the fastest available join algorithm.

"

Si estuviera en tu lugar simplemente haría un test de rendimiento para
detectar cúal es la consulta más eficiente.

Gustavo Larriera
Uruguay LatAm
Blog: http://sqljunkies.com/weblog/gux/
MVP profile: http://aspnet2.com/mvp.ashx?GustavoLarriera
Este mensaje se proporciona "COMO ESTA" sin garantias y no otorga ningun
derecho / This posting is provided "AS IS" with no warranties, and confers
no rights.

"Miquel" <mbusom(@)gmail(.)com> wrote in message
news:%23K8r%
> Hola,
>
> Tengo una tabla (Articulos) con unos 150.000 registros, que entre otros
> campos contiene
> strArtículo nvarchar,
> intCodigoEspecialidad int,
> intAño int
>
> y otra tabla (Especialidades), con unos 20 registros:
> intCodigoEspecialidad int,
> strEspecialidad nvarchar
>
> El usuario desea encontar un artículo mediante su texto y la consulta es
> del
> tipo
>
> create procedure buscaArticulo (@Art nvarchar(..), @CodiEspecialidad > > null)
> as
> select strArticulo from articulo inner join especialidades on
> articulos.intCodigoEspecialidad = especialidades.intCodigoEspecialidad
> where
> strArículo like @art + '%' and (@CodigoEspecialidad is null or
> intCodigoEspecialidad = @CodigoEspecialidad)
>
> Pues bien.
> Con los índices que tenia antes, el plan de ejecución hacia un HASH

MATCH/

> RIGHT OUTER JOIN entre las dos tablas con CLUSTERED INDEX SCAN para las
> dos,
> y con unos costos de 50% y 67%
> Al crear los indices que recomienda el asistente para índices, el plan

> ejecución hace MERGE JOIN /RIGHT OUTER JOIN tambien sobre las dos tablas

> con CLUSTERED INDEX SCAN pero sus costos son de 75% y 100%.
>
> Son comparables los costos si se refieren a HASH MATCH/ RIGHT OUTER JOIN
> o
> a MERGE JOIN /RIGHT OUTER JOIN ?
> O sea cual sea la operación, un costo del 75% es siempre mayor que uno

del

> 50%?
>
> Grácias
>
>

Siga el debate Respuesta

Responder a este mensaje

Ads by Google

Hacer una pregunta

Tengo una respuesta

1 2

Busqueda sugerida