SQL Server - производительность запросов больших таблиц с GROUP BY

Question

У меня есть таблица «TRANSACTION» на Sql Server 2008. Приблизительно 6 записей за 1 секунду вставляются в эту таблицу. (Так как это таблица финансовых транзакций) Итак, через 1 день вставляется 500 000 записей. Таблица разделяется еженедельно.

Эта таблица в значительной степени используется для многих видов выбора (с помощью NOLOCK, конечно), вставки, операции обновления.

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

Обратите внимание, что столбцы в списке выбора НЕ индексируются в таблице.

SET @END_DATE = GETDATE() 

SET @START_DATE = DATEADD(HOUR, -24, @END_DATE) 

SELECT Column1, Column2, Column3, Column4, COUNT(*) FROM [TRANSACTION] WITH(NOLOCK) 
WHERE TRANSACTION_DATE BETWEEN @START_DATE AND @END_DATE 
GROUP BY Column1, Column2, Column3, Column4 

Answer 1

Запуск любого запроса на сервер будет использовать CPU/Memory/IO, так что по сути все, что вы можете запустить иметь влияние на других запросов выполняется.

Вы, безусловно, будете читать в ~ 500 тыс. Строк из своих собственных цифр, размер строки, который вы могли бы рассчитать, и вы могли бы даже получить общее представление о том, сколько страниц будут храниться на этих данных. Вам нужно будет перекрестно проверить план запроса, чтобы убедиться, что он, по крайней мере, не выполняет полное сканирование разделов, иначе это будет 3,5 миллиона строк, отсканированных в памяти.

Будет ли это за пределами ваших SLA? мы не можем сказать, что только вы можете определить, что с помощью подходящего тестирования нагрузки.

Answer 2

Очевидно, что WILL более или менее замедляет все операции на сервере.

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

Лично я рекомендую вам создать индекс по столбцам Column1, Столбец2, Column3, column4, TRANSACTION_DATE чтобы запустить группировки быстрее, например:

CREATE INDEX iName on [TRANSACTION](Column1, Column2, Column3, Column4, Transaction_date)