выберите снижение производительности статов при использовании DISTINCT с параметрами

Примечание для награды - НАЧАЛО:

ПАРАМЕТРЫ ОБРАБОТКИ (это единственная «идея», о которой сообщалось в предварительном объявлении questions) здесь не проблема, как вы можете прочитать в разделе «Обновление» в конце вопроса. Я загрузил очень простую резервную копию базы данных (она работает с sql server 2008 R2) здесь (вы должны подождать 20 секунд перед загрузкой). В отношении этой БД вы можете попробовать выполнить следующие запросы:

-- PARAMETRIZED QUERY

declare @IS_ADMINISTRATOR int
declare @User_ID int
set @IS_ADMINISTRATOR = 1 -- 1 for administrator 0 for normal
set @User_ID = 50

SELECT DISTINCT -- PLEASE REMEMBER DISTINCT MAKES THE DIFFERENCE!!!
  DOC.DOCUMENT_ID
FROM
  DOCUMENTS DOC LEFT OUTER JOIN
  FOLDERS FOL ON FOL.FOLDER_ID = DOC.FOLDER_ID LEFT OUTER JOIN
  ROLES ROL ON (FOL.FOLDER_ID = ROL.FOLDER_ID)   
WHERE
  1 = @IS_ADMINISTRATOR OR  ROL.USER_ID = @USER_ID

-- NON PARAMETRIZED QUERY

SELECT DISTINCT -- PLEASE REMEMBER DISTINCT MAKES THE DIFFERENCE!!! 
  DOC.DOCUMENT_ID
FROM
  DOCUMENTS DOC LEFT OUTER JOIN
  FOLDERS FOL ON FOL.FOLDER_ID = DOC.FOLDER_ID LEFT OUTER JOIN
  ROLES ROL ON (FOL.FOLDER_ID = ROL.FOLDER_ID)   
WHERE
  1 = 1 OR  ROL.USER_ID = 50

Заключительное примечание: я заметил, что проблема с DSTINCT, моя цель - добиться одинаковой скорости (или, по крайней мере, почти одинаковой скорости) в обоих запросах.

Примечание. for bounty - END:

Исходный вопрос:

Я заметил, что существует большая разница в производительности между

-- Case A
select distinct * from table where id > 1

и (это sql, созданный моим приложением Delphi)

-- Case B1
exec sp_executesql N'select distinct * from table where id > @P1',N'@P1 int',1

, который эквивалентен

-- Case B2
declare @P1 int
set @P1 = 1
select distinct * from table where id > @P1

] A работает намного быстрее, чем B1 и B2. Производительность становится такой же, если я удалю DISTINCT.

Не могли бы вы прокомментировать это?

Здесь я разместил тривиальный запрос, я заметил это в запросе с 3 INNER JOIN. В любом случае не сложный запрос.

Примечание: Я ожидал, что в случаях A и B1 / B2 получу ТОЧНУЮ ТАКУЮ ПРОИЗВОДИТЕЛЬНОСТЬ.

Есть ли какие-то предостережения при использовании DISTINCT?

ОБНОВЛЕНИЕ :

Я попытался отключить отслеживание параметров с помощью ] DBCC TRACEON (4136, -1) (флаг для отключения анализа параметров), но ничего не меняется. Так что в данном случае проблема НЕ СВЯЗАНА С СНИФФИЦИЕМ ПАРАМЕТРОВ. Есть идеи?