I'm getting a SQL Timeout from a stored procedure on a specific OR condition - why? [closed]

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center. Closed 11 years ago.

I have开发者_如何学编程 a simple query with a few joins. The query has a about 4 or 5 WHERE conditions, but it takes up to 15 seconds to return NO results. However, if I exclude a specific OR condition, it takes only 5 seconds and returns about 20 rows.

Anyway, I thought that maybe I should refactor the OR's somehow, because they don't have any inner selects or anything fancy, just a simple condition on a column.

Any ideas? This doesn't seem to be a table lock problem, and I'm running the query directly through SQL Management Studio (2008 RC2 server).

---

Possibly:

1. Your statistics are not up to date
2. Your indexes need rebuilding
3. Or you are experiencing parameter sniffing
4. You have 'missing' indexes
5. A combination of the above

More detail needed.

---

Have you looked at the actual clause itself? String compares across large tables, for example, can be extremely processor-heavy. If you absolutely have to have the clause in place, perhaps you should dump a "quickie" result set into a temp table and filter further using your slow clauses from there.

You should also look at your indices - the exact same effect applies; an index or two will turn your query into a two-part search, a fast index-based lookup of potential results followed by a slow-but-limited search of the subresult.

---

Without any specifics, heres one thing I learnt.

Select * from mytable where dateadd(day,1,table_date) > getdate()

will run for AGES

whereas

select * from mytable where table_date>dateadd(day,-1,getdate())

is quicker. As the calculation can be done once and compared against a direct potential index.