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
 

Leer las respuestas

#1 Miguel Egea
04/02/2006 - 00:08 | Informe spam
Cuando hablamos del operador lógico inner join, este puede convertirse en 3
operadores físicos, merge, nested loop y hash joins. Por regla general merge
es el más eficaz de todos, pero eso lo puedes comprobar viendo el número de
lecturas lógicas resultante en uno y otro caso.

En tu sentencia, yo la reescribiría con un if, seguramente sea mucho más
eficaz
create procedure buscaArticulo (@Art nvarchar(..), @CodiEspecialidad =
null)
as
if not @codigoEspecialidad is null
select strArticulo from articulo inner join especialidades on
articulos.intCodigoEspecialidad = especialidades.intCodigoEspecialidad
where
strArículo like @art + '%' and intCodigoEspecialidad =
@CodigoEspecialidad
else
select strArticulo from articulo inner join especialidades on
articulos.intCodigoEspecialidad = especialidades.intCodigoEspecialidad
where
strArículo like @art + '%'


Además asegurate de tener un índice por sarticulo,intCodigoEspecialidad y
uno más por sarticulo solamente. y nos cuentas que tal te fué.


Miguel Egea
Visita mi web http://www.portalsql.com
SQL Server MVP, Mentor
Solid Quality Learning
http://www.SolidQualityLearning.com
"Solid Quality Learning is the trusted global provider of advanced education
and solutions for the entire Microsoft database platform"


"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 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


Preguntas similares