Pergunta

Profiling LINQ consulta e seus planos de execução é especialmente importante devido ao SQL louca que às vezes pode ser criado.

muitas vezes eu achar que eu preciso para rastrear uma consulta específica e ter um achado dificuldade em analisador de consulta. Costumo fazer isso em um banco de dados que tem um monte de correr transações (às vezes servidor de produção) - assim apenas abrindo Profiler não é bom

.

Eu também encontrei tentando usar o DataContext para traçar inadequada, uma vez que ele não me dê SQL eu posso realmente me executar.

Meu melhor estratégia até agora é adicionar um número 'aleatório' para a minha consulta e filtro para ele no rastreio.

LINQ:

where o.CompletedOrderID != "59872547981"

filtro Profiler:

'TextData' like '%59872547981'

Esta multa trabalha com algumas ressalvas:

  • Eu tenho que ter cuidado para não se esqueça de remover os critérios, ou escolher algo que não vai afetar o plano de consulta muito. Sim, eu sei deixá-lo em está pedindo para ter problemas.
  • Tanto quanto eu posso dizer, porém, mesmo com essa abordagem eu preciso para começar um novo rastreamento para cada consulta LINQ que eu preciso para rastrear. Se eu for para 'Arquivo> Propriedades' para um traço existente Eu não posso mudar os critérios de filtro.

Você não pode superar a executar uma consulta no seu aplicativo e vê-lo aparecer no Profiler sem qualquer esforço extra. Estava apenas esperando que alguém tinha vir para cima com uma maneira melhor do que isso, ou pelo menos sugerir um menos 'perigoso' token para procurar do que uma consulta em uma coluna.

Foi útil?

Solução

Messing com o onde cláusula não é talvez a melhor coisa a fazer, uma vez que pode e vai afetar os planos de execução para suas consultas.

Faça algo funky com projeção em classes anônimas em vez - use um nome de coluna estático exclusivo ou algo que não vai afetar o plano de execução. (Dessa forma, você pode deixá-lo intacto no código de produção no caso de você mais tarde precisar fazer qualquer profiling de código de produção ...)

from someobject in dc.SomeTable
where someobject.xyz = 123
select new { MyObject = someobject, QueryTraceID1234132412='boo' }

Outras dicas

Você pode usar o LINQ to SQL Debug Visualiser - http://weblogs.asp.net/scottgu/archive/2007/07/31/linq-to-sql-debug-visualizer.aspx e vê-lo na janela do seu relógio.

Ou você pode usar DataContext.GetCommand(); para ver o SQL antes de executar.

Você também pode olhar para o DataContext.GetChangeSet() para ver o que vai ser inserida / atualizada ou excluída.

Você pode ter seu log datacontext o SQL cru, que você pode então procurar no profiler para examinar o desempenho.

using System.Diagnostics.Debugger;

yourDataContext.Log = new DebuggerWriter();

Todas as suas consultas SQL será exibido na janela de saída do depurador agora.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top