SQL Server - производительность запросов больших таблиц с помощью GROUP BY - PullRequest
0 голосов
/ 18 января 2012

У меня есть таблица «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

Ответы [ 2 ]

3 голосов
/ 18 января 2012

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

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

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

0 голосов
/ 18 января 2012

Очевидно, что БУДЕТ более или менее замедлять все операции на сервере.

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

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

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