Что такое «ПАРАЛЛЕЛЬНЫЙ» эквивалент в SQL Server

Question

У меня есть эта проблема, когда мне нужно сделать COUNT(COLUMN_NAME) и SUM(COLUMN_NAME) на нескольких таблицах. Проблема в том, что это время на SQL Server для этого.

У нас есть более 2 миллиардов записей, для которых мне необходимо выполнить эти операции.

В Oracle мы можем принудительно выполнить параллельное выполнение для одного запроса/сеанса с помощью подсказки PARALLEL. Например, для простого SELECT COUNT, мы можем сделать

SELECT /*+ PARALLEL */ COUNT(1) 
FROM USER.TABLE_NAME; 

Я искал, если есть что-то для SQL Server, и я не мог comeup с чем-то конкретным, где я могу указать таблицу подсказку для параллельного выполнения. Я полагаю, SQL Server сам решает, выполнять ли параллельное или последовательное выполнение в зависимости от стоимости запроса.

Тот же запрос в Oracle с параллельным намеком занимает 2-3 минуты для выполнения, тогда как на SQL Server это занимает около часа и половины.

Answer 1

Я читаю статью Forcing a Parallel Query Execution Plan. Для меня это похоже на то, что вы могли бы проверить целевую силу на параллельное выполнение. Автор говорит, что в conclution:

Заключение

Даже специалисты с многолетним опытом работы SQL Server и подробные внутреннего знания будут хотеть быть осторожным с этим флагом. I не может рекомендовать вам использовать его непосредственно в производстве, если только он не рекомендован Microsoft, но вы можете использовать его в тестовой системе как крайний последней инстанцией, возможно, для создания плана или подсказки USE PLAN для использования в производстве (после тщательного анализа).

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

Статья ссылается на флаг трассировки:

Там всегда Trace Flag

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

Так насколько мои понимание этой статьи вы могли бы сделать что-то вроде этого:

SELECT 
    COUNT(1) 
FROM 
    USER.TABLE_NAME 
OPTION (RECOMPILE, QUERYTRACEON 8649) 

Answer 2

в оракула, если делать SELECT COUNT() на колонке, то SQL будет следовать индекс. В приведенном ниже плане вы можете увидеть «INDEX FAST FULL SCAN», это ускорит выполнение sql. Вы можете попробовать то же самое в sqlserver, у вашей таблицы есть индекс. Попробуйте создать индекс в столбце, в котором вы подсчитываете. Но в случае оракула он будет использовать любой другой индекс столбца.В ниже sql есть «count (DN)», но он использует индекс другого столбца.

SQL> set linesize 500 
SQL> set autotrace traceonly 
SQL> select count(DN) from My_TOPOLOGY; 

Execution Plan 
---------------------------------------------------------- 
Plan hash value: 2512292876 

-------------------------------------------------------------------------------- 
| Id | Operation    | Name   | Rows | Cost (%CPU)| Time  | 
-------------------------------------------------------------------------------- 
| 0 | SELECT STATEMENT  |    |  1 | 164 (64)| 00:00:01 | 
| 1 | SORT AGGREGATE  |    |  1 |   |   | 
| 2 | INDEX FAST FULL SCAN| FM_I2_TOPOLOGY | 90850 | 164 (64)| 00:00:01 | 
-------------------------------------------------------------------------------- 


Statistics 
---------------------------------------------------------- 
      1 recursive calls 
      0 db block gets 
     180 consistent gets 
     177 physical reads 
      0 redo size 
     529 bytes sent via SQL*Net to client 
     524 bytes received via SQL*Net from client 
      2 SQL*Net roundtrips to/from client 
      0 sorts (memory) 
      0 sorts (disk) 
      1 rows processed