Início / dba / Perguntas / 331438
Accepted
Vipin
Asked: 2023-09-21 22:05:02 +0800 CST

Desempenho de consulta do SQL Server: busca de índice no SSMS, mas verificação de índice em aplicativo Java

  • 772

Estou enfrentando um problema com o desempenho da consulta do SQL Server e espero obter alguns insights de todos vocês.

Declaração do problema:

Eu tenho uma consulta SQL que funciona bem (~6 ms) quando executada diretamente no SQL Server Management Studio (SSMS), mostrando uma "Busca de índice" no plano de execução. No entanto, quando a mesma consulta é executada em meu aplicativo Java usando JDBC, o plano de execução mostra uma "Varredura de índice" e a consulta leva muito mais tempo (~ 1 segundo) para ser executada.

O que eu tentei:

  1. Garantiu que as estatísticas estejam atualizadas nas tabelas e índices envolvidos.
  2. Comparamos as configurações de contexto de execução entre o SSMS e o aplicativo Java.
  3. Adicionado SQL ao produto armazenado e então funciona bem, faz busca de índice.
  4. ID do plano removido, cache limpo.

Pergunta:

  1. O que poderia estar causando essa discrepância no desempenho da consulta?
  2. Há alguma etapa de depuração que eu possa ter perdido?

Planeje quando isso será executado em Java: https://www.brentozar.com/pastetheplan/?id=SkWWezsya

Planeje quando isso será executado a partir do SSMS: https://www.brentozar.com/pastetheplan/?id=HJZPefokp

Quaisquer ideias ou sugestões serão muito apreciadas.

sql-server

3 respostas

  1. Best Answer

    Os planos de consulta em sua pergunta mostram que o tipo de dados do parâmetro SSMS é varchar(8000)enquanto o tipo de parâmetro JDBC é nvarchar(4000). O plano SSMS é capaz de usar um operador de busca eficiente porque o varchartipo de parâmetro corresponde ao varchartipo de coluna, mas a conversão implícita da coluna no nvarcharplano JDBC por regras de precedência de tipo de dados resulta em uma expressão não sargável, exigindo uma varredura.

    Acrescentarei que a conversão implícita não seria um grande problema com um agrupamento do Windows porque o SQL Server poderia forçar uma expressão sargável com um predicado de busca de intervalo usando GetRangeThroughConvert .

    Você pode transmitir varcharparâmetros de aplicativos JDBC especificando sendStringParametersAsUnicode=false na cadeia de conexão. Trecho relevante do documento JDBC:

    Para obter desempenho ideal com os tipos de dados JDBC CHAR, VARCHAR e LONGVARCHAR, um aplicativo deve definir a propriedade sendStringParametersAsUnicode como "false" e usar os métodos de caracteres não nacionais setString, setCharacterStream e setClob das classes SQLServerPreparedStatement e SQLServerCallableStatement.

    Se você também precisar passar parâmetros Unicode, use os setNmétodos de SQLServerPreparedStatement:

    Um aplicativo deve usar os métodos de caracteres nacionais setNString, setNCharacterStream e setNClob das classes SQLServerPreparedStatement e SQLServerCallableStatement para os tipos de dados JDBC NCHAR, NVARCHAR e LONGNVARCHAR.

    A respeito de:

    1. Adicionado SQL ao produto armazenado e então funciona bem, faz busca de índice.

    O parâmetro do procedimento armazenado foi aparentemente definido como varchar. Nesse caso, o nvarcharvalor do parâmetro fornecido pelo aplicativo foi convertido implicitamente no varcharparâmetro definido pelo proc antes da execução do procedimento. O plano de execução do proc utilizou então o varcharparâmetro sem nenhuma conversão, permitindo a busca do índice.

    Vale ressaltar que os procedimentos armazenados, com tipos de parâmetros adequados, podem ajudar a mitigar problemas com tipos de parâmetros inadequados passados ​​por aplicativos clientes porque os procedimentos são compilados e otimizados com a definição de parâmetro proc em vez da definição de parâmetro fornecida pelo cliente.

    • 4

  2. Sim, conforme comentários de @DanGuzman e @DenisRubashkin, você tem um parâmetro nvarchar.

    <ParameterList>
              <ColumnReference Column="@P0" ParameterDataType="nvarchar(4000)" ParameterCompiledValue="N'5008K0000046zJGQAY'" />
</ParameterList>

    Você terá que coagir seu cliente a enviar como varchar.

    Vejo isso o tempo todo em .NET/Entity Framework/LINQ. É insidioso porque funciona em pequenos conjuntos de dados de desenvolvimento/teste/UAT, mas problemas de desempenho se manifestam em cargas de trabalho e conjuntos de dados de produção.

    Parâmetros adicionados com AddWithValue ou similar farão isso. Unicode nativo == nvarchar, não varchar e como ANSI SQL exige uma conversão nos valores da tabela, não nos parâmetros, você obtém varreduras no índice em vez de buscas adequadas :(

    • 2

  3. O XML do seu plano Java confirma que a conversão implícita de VARCHAR para NVARCHAR está afetando o plano:

    <PlanAffectingConvert ConvertIssue="Seek Plan" Expression="CONVERT_IMPLICIT(nvarchar(18),[CCIP].[salesforce].[Case].[Id],0)=[@P0]" />
    • 1

relate perguntas