Início / dba / Perguntas / 164808
Accepted
eckes
Asked: 2017-02-19 14:11:19 +0800 CST

Por que essa busca em BIGINT col tem operadores extras de varredura constante, escalar de computação e loops aninhados?

  • 772

Quando olho para o plano de execução real de algumas de minhas consultas, percebo que as constantes literais usadas em uma cláusula WHERE aparecem como uma cadeia aninhada de varredura escalar e constante calculada .

captura de tela do sql studio

Para reproduzir isso, eu uso a seguinte tabela

CREATE TABLE Table1 (
    [col1] [bigint] NOT NULL,
    [col2] [varchar](50) NULL,
    [col3] [char](200) NULL
)
CREATE NONCLUSTERED INDEX IX_Table1 ON Table1 (col1 ASC)

Com alguns dados nele:

INSERT INTO Table1(col1) VALUES (1),(2),(3),
                               (-9223372036854775808),
                               (9223372036854775807),
                               (2147483647),(-2147483648)

Quando executo a seguinte consulta (sem sentido):

SELECT a.col1, a.col2
  FROM Table1 a, Table1 b
  WHERE b.col1 > 2147483648

Vejo que ele fará um desenho de Loop Aninhado no resultado de Index Seek e um cálculo escalar (a partir de uma constante).

Observe que o literal é maior que maxint. Ajuda a escrever CAST(2147483648 as BIGINT). Alguma idéia de por que o MSSQL está adiando isso para o plano de execução e existe uma maneira mais curta de evitá-lo do que usar o elenco? Isso afeta os parâmetros vinculados às instruções preparadas (do jtds JDBC) também?

O cálculo escalar nem sempre é feito (parece ser específico de busca de índice ). E às vezes o analisador de consultas não mostra isso graficamente, mas como col1 < scalar(expr1000)nas propriedades do predicado.

Eu vi isso com o MS SSMS 2016 (13.0.16100.1) e SQL Server 2014 Expres Edition 64 bits no Windows 7, mas acho que é um comportamento geral.

sql-server sql-server-2014

2 respostas

  1. Best Answer
    SELECT thing, 
       sql_variant_property(thing,'basetype') AS basetype,
       sql_variant_property(thing,'precision') AS precision, 
       sql_variant_property(thing,'scale') AS scale
FROM (VALUES (2147483648)) V(thing)

    Mostra que o literal 2147483648é interpretado como numeric(10,0). Esse comportamento é anterior à introdução do bigintno SQL Server (2000).

    Não há sintaxe para indicar que um literal deve ser tratado como bigint- adicionar um explícito CASTé a melhor solução. O artigo Buscas Dinâmicas e Conversões Implícitas Ocultas discute o resto do aparato no plano.

    O próprio plano mostra que os loops aninhados têm um predicado de busca em

    Seek Keys[1]: Start: [tempdb].[dbo].[Table1].col1 > Scalar Operator([Expr1005]), 
                End: [tempdb].[dbo].[Table1].col1 < Scalar Operator([Expr1006])

    Você pode usar uma sessão de eventos estendidos query_trace_column_valuespara ver que são os seguintes.

    insira a descrição da imagem aqui

    O XML no plano também mostra isso

      <DefinedValue>
    <ValueVector>
      <ColumnReference Column="Expr1005" />
      <ColumnReference Column="Expr1006" />
      <ColumnReference Column="Expr1004" />
    </ValueVector>
    <ScalarOperator ScalarString="GetRangeWithMismatchedTypes((2147483648.),NULL,(6))">
      <Intrinsic FunctionName="GetRangeWithMismatchedTypes">
        <ScalarOperator>
          <Const ConstValue="(2147483648.)" />
        </ScalarOperator>
        <ScalarOperator>
          <Const ConstValue="NULL" />
        </ScalarOperator>
        <ScalarOperator>
          <Const ConstValue="(6)" />
        </ScalarOperator>
      </Intrinsic>
    </ScalarOperator>
  </DefinedValue>

    Isso não significa que ele está literalmente fazendo uma comparação < nullem vez de

    As expressões de limite de intervalo usam NULL para representar 'ilimitado' em qualquer extremidade. ( Fonte )

    Portanto, o efeito líquido é que seu predicado de consulta b.col1 > CAST(2147483648 AS NUMERIC(10, 0))ainda acaba com uma busca contrab.col1 > CAST(2147483648 AS BIGINT)

    Isso afeta os parâmetros vinculados às instruções preparadas (do jtds JDBC) também?

    Eu não usei jtds JDBC, mas presumo que permita definir tipos de dados de parâmetro? Nesse caso, apenas certifique-se de que os parâmetros sejam o tipo de dados correto que corresponda à coluna ( bigint) para que não haja necessidade de o SQL Server lidar com tipos de dados incompatíveis.

    • 9

  2. Em relação à minha pergunta sobre as declarações preparadas pelo JDBC. jTDS usa sp_prepare/ sp_execute(no modo padrão prepareSQL=3).

    Com a seguinte consulta ( source ):

    use database
select
    cp.objtype, st.text
from sys.dm_exec_cached_plans cp
cross apply sys.dm_exec_sql_text(cp.plan_handle) st
where cp.objtype = 'prepared' and st.text like '%TABLE%'

    Eu posso ver a instrução preparada conforme emitida pelo JTDS e ela declara a variável conforme (@P0 bigint)...o esperado.

    Portanto, tudo isso é bom e preciso lembrar que, ao experimentar os planos de execução, é melhor definir variáveis ​​de tipo local em vez de substituí-las por literais (e/ou usar sp_executepara acessar o plano de execução em cache).

    • 3

relate perguntas