Увеличение числа строк, возвращаемых «select top», неожиданно делает запрос невероятно медленным

Question

Нагрузка, которая работала в течение примерно 2 минут, внезапно превратилась в 90-минутный прогон, а затем была отменена вручную.

Это простой теневой запрос:

select fields
into shadow_table
from table
where date = '8/23/2011'

date имеет некластеризованный индекс.

Если я изменю запрос на выбор

• top 300000 завершается за 2 секунды
• top 400000 работает за 3 минуты
• top 500000 Мне надоело ждать и я отменил это

Наша серверная команда показывает много самоблокировок во время работы.

Кто-нибудь может подсказать возможные узкие места, на которые стоит посмотреть?

Answer 1

Статистика устарела.

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

Шаг 1 должен выполнить UPDATE STATISTICS WITH FULLSCAN в исходной таблице.

Answer 2

Следуйте проверенной методике Ожидания и очереди для выявления узкого места.

Когда запрос выполняет параллельный запрос, правильный способ анализа блокировки - это погружение на уровне подзадачи и посмотреть, чтоблокирует каждый подзадач.Никогда не следует останавливаться на CXPACKET в качестве типа ожидания или на «самоблокировке» в качестве объяснения.

select w.last_wait_type, 
    wt.wait_type, 
    wt.resource_description, 
    wt.blocking_session_id, 
    t.pending_io_count, 
    r.* 
from sys.dm_os_tasks t
left join sys.dm_os_waiting_tasks wt on wt.waiting_task_address = t.task_address
join sys.dm_os_workers w on t.worker_address = w.worker_address
join sys.dm_exec_requests r on t.session_id = r.session_id
where r.session_id = <queryspid>;

Answer 3

Также убедитесь, что ваши поля включены как часть вашего некластеризованного индекса. Если вы этого не сделаете, вам придется вернуться к таблице, используя поиск RID, чтобы получить эти данные.

create nonclustered index ix_whatever on YourTable (date) 
include (field1, field2, ...)

Answer 4

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