Estou colocando uma consulta para listar as pesquisas de chave que estão presentes nas solicitações atuais que estão sendo executadas, basicamente gostaria de abordá-las e ver se poderia eliminar essas pesquisas de chave do plano de execução .
Para chegar a essas pesquisas de chave, uso a seguinte consulta:
SELECT
er.session_id,
er.blocking_session_id,
er.start_time,
er.status,
dbName = DB_NAME(er.database_id),
er.wait_type,
er.wait_time,
er.last_wait_type,
er.granted_query_memory,
er.reads,
er.logical_reads,
er.writes,
er.row_count,
er.total_elapsed_time,
er.cpu_time,
er.open_transaction_count,
er.open_transaction_count,
s.text,
qp.query_plan,
logDate = CONVERT(DATETIME,GETDATE()),
logTime = CONVERT(DATETIME,GETDATE())
FROM sys.dm_exec_requests er
CROSS APPLY sys.dm_exec_sql_text(er.sql_handle) s
CROSS APPLY sys.dm_exec_query_plan(er.plan_handle) qp
WHERe er.session_id <> @@SPID
and CONVERT(VARCHAR(MAX), qp.query_plan) LIKE '%IndexScan Lookup%'
O problema que estou enfrentando com esta consulta é que ela retorna qualquer key lookup
independentemente do seu custo .
Gostaria de filtrá-los, gostaria apenas de ver as pesquisas de chave caras .
Como posso filtrar minha consulta para mostrar apenas as operações de pesquisa caras ?
Isso não é uma boa ideia.
Tire isso de mim. Há muito tempo atrás eu codifiquei um cheque
sp_BlitzCache
que encontrou planos com pesquisas de chave neles e, em seguida, comparei o custo dessa operadora com o custo total do plano. Se fosse > 50% ou algo assim, eu sinalizaria como caro.Eu não faria isso nunca mais.
O problema é que o custo tem absolutamente zero significado no mundo real Kelvin. Isso se tornou mais óbvio com os tempos do operador presentes nos planos de consulta.
Correr por aí corrigindo cada pesquisa de chave provavelmente não resolverá seus piores problemas de desempenho e provavelmente acabará com muitos índices muito amplos.
Sua melhor aposta é encontrar consultas para ajustar com base no consumo médio de CPU, ou aquelas que são conhecidas por causar problemas comerciais específicos, e ajustar as partes realmente lentas desses planos.
As pesquisas de chave não indicam um problema de desempenho, assim como os altos custos de um plano ou operadora não indicam. Você precisa obter o plano de execução real para descobrir o que está com baixo desempenho.
Você pode usar XQuery para filtrar o plano XML. Por exemplo:
O que isso faz é o seguinte:
ShowPlanXML/BatchSequence/Batch/Statements/*
nó onde*
significa qualquer nome .StatementSubTreeCost
atributo, converte paradecimal
depois divide por2
(você pode escolher outro cálculo).RelOp
,IndexScan
que tem um atributoLookup
que tem um valor1
EstimatedTotalSubtreeCost
atributo1
db<>violino