plan de ejecución estimado

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

Miguel,

No se mucho sobre la estructura de las tablas, asi como los indices con que
cuentas. Te comento que la expresion que usas para filtrar en la clausula
"where", no es recomendada.

where
strArículo like @art + '%' and (@CodigoEspecialidad is null or
intCodigoEspecialidad = @CodigoEspecialidad)

Sin cambiar los indices, compara los planes de ejecucion entre la sentencia
que posteastes y esta.

...
where
strArículo like @art + '%'
or intCodigoEspecialidad between coalesce(@CodigoEspecialidad, 0) and
coalesce(@CodigoEspecialidad, 2147483647)
go


Dynamic Search Conditions in T-SQL
http://www.sommarskog.se/dyn-search.html


AMB


"Miquel" wrote:

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

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

Hola,
He estado probando como tu decias.
Tal y como tú indicas, crea un plan de ejecución con dos operaciones físicas
(dos nested loops) sobre seeks en los índices.
Además, hace un 7 u 8% menos de lecturas lógicas.

Muchas grácias

"Miguel Egea" escribió en el mensaje
news:

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

Hola,
No conocia esto del COALESCE.
Haciendo como tu dices, me conserva el MERGE´. Lo que no entiendo, es que
ahora todo me marca costo 0%
Supongo que no es una "ciencia exacta", porque haciéndolo como tu dices, me
hace más "reads" que como lo tenia yo, o que como dice Miguel Egea, pero en
cambio la duración es mucho menor

Muchas grácias,


"Alejandro Mesa" escribió en el
mensaje news:

Miguel,

No se mucho sobre la estructura de las tablas, asi como los indices con

que

cuentas. Te comento que la expresion que usas para filtrar en la clausula
"where", no es recomendada.

> where
> strArículo like @art + '%' and (@CodigoEspecialidad is null or
> intCodigoEspecialidad = @CodigoEspecialidad)

Sin cambiar los indices, compara los planes de ejecucion entre la

sentencia

que posteastes y esta.

...
where
strArículo like @art + '%'
or intCodigoEspecialidad between coalesce(@CodigoEspecialidad, 0) and
coalesce(@CodigoEspecialidad, 2147483647)
go


Dynamic Search Conditions in T-SQL
http://www.sommarskog.se/dyn-search.html


AMB


"Miquel" wrote:

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