19. Otimização de consultas KQL

Uma consulta KQL eficiente reduz cedo o conjunto que precisa de operações caras e transporta apenas o resultado necessário. Essa redução deve preservar a pergunta original: trocar um operador por outro mais rápido não é válido quando muda quais eventos correspondem.

Filtros e projeção

Restrinja a tabela e o intervalo temporal pertinentes antes de parsing e manipulação custosa de campos dynamic quando isso preservar a lógica. Processar milhões de payloads para depois descartar quase todos desperdiça trabalho. Projete as colunas necessárias para reduzir transporte e memória em etapas seguintes.

Evite pesquisar todas as colunas quando o contrato aponta um campo específico. Além do custo, a busca ampla pode encontrar correspondências em atributos que não deveriam participar da condição. Eficiência e precisão semântica frequentemente melhoram juntas quando o escopo é explícito.

Filtrar tempo antes de interpretar um payload dynamic pode reduzir muito o número de linhas submetidas ao parsing. Entretanto, a ordem deve preservar a lógica: se o campo temporal precisa ser extraído do payload, essa extração é um pré-requisito do filtro. A recomendação é reduzir cedo onde for semanticamente possível, e não rearranjar operadores mecanicamente. Projete apenas o necessário e verifique se algum campo removido ainda participa de joins, agrupamentos ou do resultado esperado.

Termos, substrings e caixa

has procura termos segundo sua semântica; contains procura substrings. Amer pode aparecer dentro de America e satisfazer contains sem constituir o mesmo termo para has. Substituir operadores exige demonstrar que o domínio e a pergunta são compatíveis.

Operadores sensíveis a maiúsculas podem oferecer vantagens em cenários adequados, mas mudam resultados quando o negócio ignora caixa. Normalize de forma controlada ou use a operação que atende ao contrato. Não transforme uma otimização de string em exclusão silenciosa de eventos válidos.