Почему операция сортировки перед вложенными циклами (внутреннее объединение)?

Question

У меня есть 2 экземпляра сервера Sql и один запрос:

SELECT 
    [DetailDescription],
    [SubTotal]
FROM [dbo].[CRR] WITH (INDEX (IX_CORM_CORMId))
WHERE CORM_CORMId >= 5933168 AND CORM_CORMId <= 5955843

Это приводит к двум планам выполнения запросов:

Вот выложенная версия

Один с сортировкой получает 301740 строк и занимает 48 с, другой получает 286743 строки без сортировки - 5 с. Одна БД является несколько устаревшей копией другой. Порядок номера строк в таблице составляет 98 419 368.

Мои вопросы:

1. Я не понимаю, зачем нужна сортировка для присоединения к Nested Loops? Я пытался отключить его с помощью "OPTION (QUERYTRACEON 2340)". Опция не имеет значения вообще.
2. Почему такая большая разница во времени исполнения? Как этого избежать?

Я использую Sql Server 2014.

Обновить:

С STATISTICS IO:

Таблица "CynergyResidualRecord". Сканирование 1, логическое чтение 1226357, физическое чтение 0, чтение с опережением 0, чтение логического объекта 0, физическое чтение 1, чтение с опережением 0. Таблица "Рабочий стол". Сканирование счетчик 0, логическое чтение 0, физическое чтение 0, чтение с опережением 0, логическое чтение с бита 0, физическое чтение с бита 0, чтение с опережением чтения 0.

Answer 1

Сортировка состоит в том, чтобы получить строки в порядке CynergyResidualRecordId до выполнения поиска ключей.

Это оптимизация, поэтому поиски менее случайны, как описано здесь.

Разумеется, для сортировки 300К строк не потребуется 48 секунд - в опубликованном плане указано фактическое истекшее время для оператора сортировки, равное 281 мс.

Фактическое время, затраченное на весь план, составило 2.496 секунды, поэтому я не уверен, откуда у вас 48 секунд. Возможно, 48-секундный прогон столкнулся с блокировкой или возникла проблема с вашей методикой измерения.

Answer 2

Я думаю, что это происходит из-за устаревшей статистики. рассмотрите возможность обновления статистики для этой таблицы.

UPDATE STATISTICS [dbo].[CRR];