Veja como eu responderia, com base puramente na minha experiência e conhecimento limitado:
O SQL Server parece tomar uma decisão sobre usar o paralelismo em um plano de consulta, principalmente com base em se isso ajudará ou não uma única execução dessa consulta a retornar mais rápido. Na maioria das vezes, essa avaliação é bastante precisa; ocasionalmente, o otimizador pode fazer uma escolha que não seja tão boa. Mas em ambos os casos, não leva em conta o que mais está acontecendo com esse servidor. Em particular, se você estiver executando um servidor que está manipulando um grande número de solicitações de lote por segundo, e algumas partes significativas desses lotes estiverem sendo paralelizadas, será possível encontrar a privação de encadeamentos. Ou seja, os agendadores estão todos ocupados processando as solicitações paralelizadas ou esperando por elas e nada pode ser processado. Isso pode se manifestar como falta de resposta do SQL Server. Observe que você pode não necessariamente ver 100% de utilização da CPU. Não é da CPU que você está fora, é agendadores disponíveis. Normalmente, você espera muito CX_PACKET e, possivelmente, THREADPOOL, e uma contagem de tarefas executável média entre agendadores acima de 1.
Em algumas lojas, a carga de trabalho é tão complexa que uma decisão estratégica é tomada para eliminar completamente o paralelismo para evitar completamente esse problema. Isso pode funcionar muito bem em algumas situações, até onde sei, embora tenha falado com engenheiros da Microsoft que achavam que era uma ideia equivocada e essencialmente ruim. Nesse cenário, você não pode acelerar uma consulta com paralelismo, portanto, o tempo de execução geralmente é proporcional à utilização da CPU. Isso pode ser uma troca aceitável, especialmente se a maioria das suas solicitações em lote forem pequenas.