Question

I got a table like with 10 000 lines.

declare @a table
(
  id bigint not null,
  nm varchar(100) not null,
  filter bigint
  primary key (id)
)

A select, with 4-5 join, is taking x seconds. If a where clause is added, it’s now taking 3x seconds. The where clause:

filter = @filder or
filter is null

I applied a nonclustered index on the column, but I’m getting only 10% on perfomance.

Any tips?

edit: the perfomance issue happens when the filter column is added. all joins are on primary keys.

Answer 1

I have a few thoughts on this:

1. Chances are that your joins are joining on table.id – which is a primary key and has an index – bingo – high selectivity (because the values are unique). With it being indexed the optimizer can really optimize access to this table when it is used in joins.

2. I’m not 100% sure but – either you do not have an index on filter or it is not selective enough. If you do not have an index – the optimizer will use a table scan. If you do have an index, but it is not selective enough, it will use a table scan anyways. Scans are expensive.

3. Even if you do have an index on filter The optimizer does not like OR predicates. Basically when using an OR the optimizer might end up using an index scan instead of an index seek. Try using this instead: @filder = ISNULL(Filter, @filder as @sut13 suggested.

So to improve the performance: add an index on filter if you do not have one and adjust your where clause to not use OR as I have suggested.

Also:

You shouldn’t expect the query with the where filter to perform equal to or better than the query with 4-5 joins. If the query with the joins is more selective and makes better use of indexes it is going to perform better