Início / dba / Perguntas / 87276
Accepted
Stephen__T
Asked: 2014-12-31 10:20:22 +0800 CST

O que esses parâmetros significam no início do meu plano de consulta do SQL Server?

  • 772

Estou olhando para o plano de consulta no SQL Server Mgmt Studio e vejo algo assim:

(@P0 nvarchar(4000), @P1 nvarchar(4000)) Update...

O que significa o tipo ao lado dos parâmetros? Para este exemplo, vamos supor que a coluna para esses parâmetros seja, na verdade, varchar(64). É assim que os parâmetros estão sendo vinculados em tempo de execução?

EDITAR

Este é um aplicativo Java EE usando provedores JDBC 3.0 ou 4.0. Basicamente, temos um arquivo de propriedades cheio de instruções SQL como esta:

mySqlStatementFoo = UPDATE Schema.Table.Column set column = 1 WHERE objectID = ?

Parece que, no passado, se houvesse uma incompatibilidade de ligação, lançaríamos o parâmetro assim:

Where objectID = CAST(? AS VARCHAR(36))

Suponho que eles escolheram fazer dessa maneira, pois oferecemos suporte a vários bancos de dados. IE DB2 e Oracle. Eu não vi o Java real, mas suspeito que eles estão apenas selecionando a instrução do arquivo e enviando-a pela rede. Estou fazendo testes de carga e vendo que estamos fazendo varreduras de tabela e suspeito que o otimizador não está usando o índice correto porque os parâmetros estão sendo vinculados incorretamente.

sql-server jdbc

1 respostas

  1. Best Answer

    Sim, você provavelmente está vendo conversões implícitas devido às suposições que o SQL Server precisa fazer. É criar um plano que funcionará não apenas para o valor do parâmetro que você está passando agora, mas também para outros valores potenciais. Com strings (ou talvez JDBC? Não tenho certeza) escolhe um padrão arbitrário de 4000 e Unicode. Eu acredito que existem maneiras no JDBC de não enviar Unicode ( conversões implícitas Unicode vs. não-Unicode estão entre as mais tediosas ), mas você ainda vai lidar com o problema de comprimento (que pode ou não ser um problema em seu caso específico; novamente, não tenho certeza).

    Para evitar as conversões e suposições implícitas e, por fim, as verificações e as condições de alta CPU, você precisa fazer com que o SQL Server entenda o tipo de dados que está sendo usado no parâmetro por meio de digitação explícita/forte.

    Aqui vão minhas sugestões, em ordem de preferência:

    1. Alternar para procedimentos armazenados.
    2. Alternar para procedimentos armazenados.

    3. Declare suas variáveis ​​explicitamente, por exemplo:

      DECLARE @p1 VARCHAR(36) = ?; UPDATE ... WHERE col = @p1;

    4. Continue usando CAST/ CONVERT.

    • 7

relate perguntas