Question

Imagine that we have a query like this:

select a.col1, b.col2
from t1 a
inner join t2 b on a.col1 = b.col2
where a.col1 = 'abc'

Both col1 and col2 don’t have any index.

---

If I add another restriction on the where clause, one that is always correct but with a column with an index:

select a.col1, b.col2
from t1 a
inner join t2 b on a.col1 = b.col2
where a.col1 = 'abc'
and a.id >= 0  -- column always true and with index

May the query perform faster since it may use the index on id column?

Answer 1

Use the index on id to do what?

The most costly bit here is the join on the join columns, and id has nothing to do with that.

Most likely scenario, it makes no difference.

Possible outcome: It makes it take more, because it doesn’t work out that id is always greater than zero, so it makes an index scan to find the correct rows, and then from that obtains the same rows it would have gotten from an table-scan (it would be different perhaps if there was a INCLUDE covering the columns in question).

Outlandish outcome: Well, stranger things have happened in the world of database optimisation, so I wouldn’t eat my hat if it helped, but I’d still be mightily surprised.

Really though, forcing irrelevant work with irrelevant indices is not going to help your cause.

Edit: Actually I thought of a case where it can help. SQLServer will generally use some index to seek upon, in the absence of a directly relevant one, because seek generally does better than scan even in that case. Forcing a seek upon a different index could just feasibly improve things, if for some reason that seek was better and for some reason it picked a different one to seek on. I’d still be pretty surprised though.