Início / dba / Perguntas / 337859
Accepted
Obscure_21
Asked: 2024-03-20 04:41:28 +0800 CST

O plano de consulta parece bom, mas a consulta é lenta

  • 772

Tenho uma tabela com representação hierárquica e para modelar a estrutura em árvore é utilizada a enumeração de caminhos. Apesar de o plano de consulta ser otimizado e a consulta em si ser direta, a execução da consulta leva 4 segundos. Porém, quando removo a classificação, a consulta é rápida, mas preciso dessa classificação.

Basicamente, a consulta deve retornar os principais pais relevantes cujos filhos satisfaçam determinados critérios.

Aqui está o link para a consulta e plano de consulta: https://www.brentozar.com/pastetheplan/?id=S1njIuPRT

SELECT TOP 50 Id
FROM   Site root
WHERE  Archive = 288
       AND TypeId IN( 1 )
       AND EXISTS (SELECT 1
                   FROM   Site ch
                   WHERE  ch.[path] LIKE concat(root.Path, '%')
                          AND ch.Commercial = 0
                          AND ch.Archive = 288)
ORDER  BY root.Score DESC

insira a descrição da imagem aqui

sql-server

1 respostas

  1. Best Answer

    4 segundos de tempo de CPU para classificar 6.718 linhas certamente parecem excessivos, mas minha suposição é que esse tempo foi de fato gasto avaliando os valores no escalar de computação.

    Eu poderia produzir algo semelhante com Setup

    CREATE TABLE Site
(
Id INT IDENTITY PRIMARY KEY,
Archive INT,
TypeId INT, 
path nvarchar(300) collate latin1_general_cs_as,
Commercial bit,
Score decimal(28,10),
index [Test] (TypeId, Archive) INCLUDE (path, Score),
index [NonClusteredIndex-20240318-221753] (path)
)

INSERT Site (Archive, TypeId, path, Commercial, Score)
select top (6718) 
Archive = 288, 
TypeId = 1, 
path = CAST(CRYPT_GEN_RANDOM(300) AS NCHAR(150)), 
Commercial = 0, 
Score = CRYPT_GEN_RANDOM(1) +0
from sys.all_columns

    Consulta

    WITH root AS
(
SELECT Id, path
FROM Site
WHERE  Archive = 288
       AND TypeId IN( 1 )
ORDER BY Score DESC
OFFSET 0 ROWS
)
SELECT Id
FROM   root
WHERE  EXISTS (SELECT 1
                   FROM   Site ch WITH (FORCESEEK)
                   WHERE  ch.[path] LIKE concat(root.Path, '%')
                          AND ch.Commercial = 0
                          AND ch.Archive = 288)

    Plano de execução

    insira a descrição da imagem aqui

    Saída do gravador de desempenho do Windows

    insira a descrição da imagem aqui

    O gravador de desempenho do Windows mostra que a maior parte do tempo da CPU é consumida dentro do método Open do operador Sort quando ele está construindo a tabela de classificação e que isso é aproximadamente dividido igualmente pelos três métodos

    • sqltses.dll!I4LikeRangeInfoWStrImpl
    • sqltses.dll!WStrLikeRangeStartWStrImpl
    • sqltses.dll!WStrLikeRangeEndWStrImpl

    Eles são definidos no escalar de computação e usados ​​para a busca dinâmica .

    O valor inserido na Pathcoluna acima é um lixo bastante longo e gerado aleatoriamente. A parte gerada aleatoriamente parece mais importante, pois path = CAST(CRYPT_GEN_RANDOM(20) AS NCHAR(10))também é bastante lenta, mas, por outro lado, usar path = CAST(CRYPT_GEN_RANDOM(150) AS CHAR(150))para restringir os caracteres aos mais comuns é muito mais rápido.

    Portanto, minha conclusão é que é possível colocar coisas em uma nvarcharcoluna que podem retardar consideravelmente o cálculo do intervalo de índice correto a ser buscado e que é provavelmente isso que está causando a longa duração da classificação no seu caso.

    O que foi dito acima provavelmente criará algumas strings inválidas ucs-2- mas não tenho certeza se elas são as únicas responsáveis ​​pelo desempenho mais lento.

    • 3

relate perguntas