Sintomas
Ao preencher uma variável de tabela com muitas linhas e, em seguida, ingressar em outras tabelas, o otimizador de consultas pode escolher um plano de consulta ineficiente, que pode levar a um desempenho de consulta lento.
Resolução
Depois de aplicar esse hotfix, você pode ativar o sinalizador de rastreamento 2453 para permitir que uma variável de tabela dispare a recompilação quando um número suficiente de linhas é alterado. Isso pode permitir que o otimizador de consultas escolha um plano mais eficiente. O problema foi corrigido primeiro nos seguintes pacotes cumulativos de atualizações cumulativas e/ou Service Packs para SQL Server.
Atualização cumulativa 3 para SQL Server 2014 /en-us/help/2984923
Cada nova atualização cumulativa do SQL Server contém todos os hotfixes e todas as correções de segurança incluídas na atualização cumulativa anterior. Confira as atualizações cumulativas mais recentes do SQL Server:
Service packs são cumulativos. Cada novo Service Pack contém todas as correções que estão em Service Packs anteriores, juntamente com qualquer nova correção. Nossa recomendação é aplicar o Service Pack mais recente e a atualização cumulativa mais recente para esse Service Pack. Você não precisa instalar um Service Pack anterior antes de instalar o Service Pack mais recente. Use a tabela 1 no artigo a seguir para encontrar mais informações sobre o Service Pack mais recente e a atualização cumulativa mais recente:
Como determinar o nível de versão, edição e atualização do SQL Server e seus componentes
Informações adicionais
Quando você usa uma variável de tabela em um lote ou procedimento, a consulta é compilada e otimizada para o estado vazio inicial da variável de tabela. Se essa variável de tabela estiver preenchida com muitas linhas em tempo de execução, o plano de consulta pré-compilado talvez não seja mais ideal. Por exemplo, a consulta pode estar unindo uma variável de tabela com loop aninhado porque geralmente é mais eficiente para um pequeno número de linhas. Esse plano de consulta pode ser ineficiente se a variável de tabela tiver milhões de linhas. Uma junção de hash pode ser uma opção melhor nessas condições. Para obter um novo plano de consulta, ele precisa ser recompilado. No entanto, ao contrário de outras tabelas de usuário ou temporárias, a alteração da contagem de linhas em uma variável de tabela não aciona uma consulta recompilação. Geralmente, você pode contornar isso com a opção (recompilar), que tem seu próprio custo de sobrecarga. O sinalizador de rastreamento 2453 permite o benefício da recompilação de consultas sem a opção de recompilação. Esse sinalizador de rastreamento é diferente de OPTION (RECOMPILE) em dois aspectos principais. (1) ele usa o mesmo limite de contagem de linhas que outras tabelas. A consulta não precisa ser compilada para cada execução diferentemente da opção (RECOMPILE). Ele dispararia a recompilação somente quando a alteração da contagem de linhas exceder o limite predefinido. (2) a opção (recompilar) força a consulta a inspecionar parâmetros e otimizar a consulta para eles. Esse sinalizador de rastreamento não força a inspeção de parâmetros.Observação esse sinalizador de rastreamento deve estar ativado em tempo de execução. Você não pode usar esse sinalizador de rastreamento com QUERYTRACEON. Esse sinalizador de rastreamento deve ser usado com cautela porque ele pode aumentar o número de recompilações de consulta que podem custar mais do que economias de melhor otimização de consulta.
Status
A Microsoft confirmou que este é um problema nos produtos Microsoft listados na seção "Aplicável a".
