Индексы и производительность

В плане таблицы соединены в порядке, отличном от порядка в тексте запроса. Как это может ускорить выполнение?

Сценарий: индекс уже упорядочивает строки по клиенту, но не по дате внутри клиента. Как инкрементальная сортировка может изменить стоимость плана?

При разборе плана один и тот же набор строк читается повторно. Объясните, зачем оптимизатор может добавить оператор spool.

Объясните механизм, из-за которого один и тот же SQL-запрос получает параллельный план только при достаточно высокой оценённой стоимости.

Сценарий: после первого выполнения запроса сортировка получила недостаточно памяти и обратилась к диску, но при следующих запусках объём предоставленной памяти изменился без изменения SQL. Какой механизм это объясняет?

В куче обновление строк переменной длины резко замедлило чтение по некластеризованному индексу. Какой механизм это объясняет?

Запрос имеет быстрый план выполнения, но иногда долго не возвращает результат. Как отличить задержку из-за блокировки от высокой стоимости самого плана?

Как механизм адаптивного соединения выбирает между nested loops и hash join во время выполнения запроса?

Запрос считает строки без фильтра, но план читает некластеризованный индекс вместо таблицы. За счёт какого свойства это может быть быстрее?

Может ли материализованное представление ускорить повторяющийся агрегатный запрос, если исходные таблицы часто изменяются?