我在特定 OR 条件下从存储过程中获取 SQL 超时 - 为什么？
我有一个带有一些连接的简单查询。该查询大约有 4 或 5 个 WHERE 条件，但最多需要 15 秒才能返回 NO 结果。但是，如果我排除特定的 OR 条件，则只需 5 秒即可返回大约 20 行。
不管怎样，我想也许我应该以某种方式重构 OR，因为它们没有任何内部选择或任何花哨的东西，只是列上的一个简单条件。
有什么想法吗？这似乎不是表锁问题，我直接通过 SQL Management Studio（2008 RC2 服务器）运行查询。
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).
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
可能：
需要更多详细信息。
Possibly:
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.
没有任何具体细节，这是我学到的一件事。
将运行 AGES
而
更快。因为计算可以完成一次并与直接潜力指数进行比较。
Without any specifics, heres one thing I learnt.
will run for AGES
whereas
is quicker. As the calculation can be done once and compared against a direct potential index.