SQL - ИЛИ заставляет запрос работать очень медленно

Question

Когда я объединяю два условия в предложении WHERE моего запроса, для выполнения требуется более минуты. Если я разделился на два разных запроса, они оба работают примерно через 1 секунду.

Любые мысли? Смотрите ниже:

Это занимает более чем минута

SELECT 
    COUNT(b.BookKey) 
from 
    Books b (nolock) 
    inner join BookPublishCities bp (nolock) 
     on b.BookKey = bp.BookKey 
where 
    contains(bp.PublishRegionName, @SearchTerm) OR contains(b.BookTitle, @SearchTerm) 

Вместе они составляют около 1 вторых

SELECT 
    COUNT(b.BookKey) 
from 
    Books b (nolock) 
    inner join BookPublishCities bp (nolock) 
     on b.BookKey = bp.BookKey 
where 
    contains(bp.PublishRegionName, @SearchTerm) 

-- and... 

SELECT 
    COUNT(b.BookKey) 
from 
    Books b (nolock) 
    inner join BookPublishCities bp (nolock) 
     on b.BookKey = bp.BookKey 
where 
    contains(b.BookTitle, @SearchTerm) 

• Существует полнотекстовый индекс Books.BookTitle и BookPublishCities.PublishRegionName ,
• Обе таблицы содержат около 500 тыс. Строк. Причина, по которой я не включил PublishRegionName в таблицу Books, состоит в том, что вам разрешен только один полнотекстовый индекс для каждой таблицы.
• Существует индекс на BookPublishCities.BookKey

Я просто не знаю, почему отдельные запросы намного быстрее. Мысли?

Answer 1

or может представлять проблему для оптимизаторов SQL. Обычно эта проблема возникает с условиями join, но это также может происходить здесь. Попробуйте использовать union и посмотреть, если это быстрее:

SELECT COUNT(*) 
FROM ((SELECT bookkey 
     FROM BookPublishCities bp (nolock) 
     WHERE contains(bp.PublishRegionName, @SearchTerm) 
    ) UNION ALL 
     (SELECT BookKey 
     FROM Books b (nolock) 
     WHERE contains(b.BookTitle, @SearchTerm) 
    ) 
    ) b; 

Обратите внимание, что я упростил подзапросов. join s не кажутся необходимыми с учетом логики - хотя в некоторых случаях они могут быть важными (например, если соединения используются для фильтрации, поскольку ключи книги не находятся в обеих таблицах).

Это также может не возвращать точно такие же результаты, потому что предположительно название и регион могут совпадать. Это также может генерировать дубликаты в вашем запросе, поэтому вам может понадобиться count(distinct) во внешнем запросе.

Answer 2

Set SHOWPLAN_ALL on. Осмотрите план комбинации и сравните ее с физическими лицами. Возможно, вам понадобится дать некоторые подсказки для QEP