То, как вы это написали, - это один из способов. Это часто можно увидеть с помощью NOT EXISTS
SELECT
[mChapterID]
,[ChapterName]
FROM [dbo].[ModuleChapters]
WHERE [mChapterID] NOT EXISTS (SELECT 1
FROM [dbo].[Doc2ChaptAssignment]
WHERE [DocID_FK] = @SearchTerm
AND [mChapterID_FK] = [mChapterID])
AND [ChapterName] LIKE '%'+@1+'%'
ORDER BY [ChapterName]
Реже это выглядит как JOIN
SELECT
[mChapterID]
,[ChapterName]
FROM [dbo].[ModuleChapters]
LEFT JOIN [dbo].[Doc2ChaptAssignment] on [mChapterID_FK] = [mChapterID]
WHERE [ChapterName] LIKE '%'+@1+'%'
AND [mChapterID_FK] IS NULL
ORDER BY [ChapterName]
Вероятно, вы не увидите увеличения производительности сразу, потому что ни один изВаши столбцы являются NULLable. Однако, если это когда-либо изменится, NOT IN
придется выполнить больше работы , чтобы получить те же результаты, и, таким образом, NOT EXISTS
будет быстрее. В нынешнем виде нам нужно будет увидеть план выполнения и ваши операторы DDL для любых индексов. Посмотрите в этом блоге, что получает помощь при медленном запросе. .
Обратите внимание, у вас есть не-SARGable предикат , что означает, что поиск по индексу не может быть использовандля этой части [ChapterName] LIKE '%'+@1+'%'
. Брент Озар объясняет, почему это медленно, , но суть в том, что если вы можете опустить этот опережающий%, то вы могли бы увидеть увеличение производительности. Или, что еще лучше, если вы можете использовать операнд =
(вы не ищете главы как «термин»), и у вас есть индекс покрытия, это может быть намного быстрее.