sql-sentinel

Visão Geral

Uma habilidade de análise estática que audita SQL para os anti-padrões de custo e desempenho que dominam as contas de data warehouse — SELECT *, varreduras de tabela completa, predicados não-sargable, junções cartesianas, a armadilha de NULL NOT IN, e mais 15. Ele pontua a saúde das consultas do data warehouse de 0 a 100 (A-F) e gera um plano priorizado de redução de custos, com cada descoberta contendo um why, uma fix concreta e uma economia estimada.

Construído para engenheiros de análise (dbt, Looker), equipes de plataforma de dados executando iniciativas de FinOps / "reduzir gastos com nuvem" e qualquer pessoa que revise um pull request de SQL antes que ele chegue à produção. Funciona em BigQuery, Snowflake, Redshift e Postgres. Zero dependências, licenciado sob MIT.

O motor executável e o conjunto completo de regras estão no repositório fonte: https://github.com/takeaseatventure/sql-sentinel. Trate esse repositório como código executável de terceiros.

Quando Usar Esta Habilidade

• Um usuário escreve ou revisa uma consulta para BigQuery, Snowflake, Redshift, Postgres ou Spark SQL.
• Um usuário pergunta "por que essa consulta é tão lenta?" ou "por que minha conta do data warehouse é tão alta?"
• Um usuário está prestes a promover uma consulta de dashboard ou um modelo dbt para produção.
• Um engenheiro de dados quer um segundo par de olhos antes de uma revisão de código ou uma varredura de otimização de custos.
• Uma equipe está executando uma iniciativa de "reduzir gastos com nuvem" ou FinOps.

Como Funciona

O motor divide um script SQL em instruções (respeitando aspas e comentários), executa 20 regras sobre cada instrução, pontua a saúde de 0 a 100 ponderada pela gravidade (crítica 25, alta 12, média 5, baixa 1) e retorna um plano priorizado de redução de custos.

Passo 1: Execute a auditoria

Instale ou clone o repositório fonte somente após escolher um commit, tag ou release revisado para confiar. Não execute código de um branch padrão mutável apenas porque esta habilidade aponta para ele:

git clone https://github.com/takeaseatventure/sql-sentinel.git
cd sql-sentinel
git checkout <reviewed-commit-or-tag>
node scripts/sql-sentinel.js path/to/query.sql

Ou programaticamente:

const { auditSql } = require('./scripts/sql-sentinel');
const report = auditSql(yourSqlString, { dialect: 'bigquery' });
console.log(report.healthScore);      // 0-100
console.log(report.grade);            // 'A' | 'B' | 'C' | 'D' | 'E' | 'F'
console.log(report.prioritizedPlan);  // array, worst findings first

Passo 2: Leia o plano priorizado

A saída começa com descobertas críticas (junções cartesianas, DELETE em massa) e desce para problemas de estilo de baixa gravidade. Cada descoberta explica por que ela custa dinheiro e como corrigi-la.

Exemplos

Exemplo 1: Uma consulta de dashboard bagunçada

SELECT DISTINCT *
FROM user_events, raw_logs
WHERE LOWER(event_name) LIKE '%signup%'
  AND user_id NOT IN (SELECT id FROM deleted_users)
ORDER BY created_at;

A auditoria pontua esta consulta em 17/100 (nota F) e sinaliza 7 descobertas:

• CRÍTICA: junção por vírgula produz um produto cartesiano (pode transformar uma consulta de $0,02 em uma de $200)
• ALTA: SELECT * força varredura completa de colunas (30-90% de bytes desperdiçados em tabelas largas)
• ALTA: wildcard inicial LIKE '%signup%' derrota índices
• ALTA: LOWER(event_name) derrota índices (não-sargable)
• ALTA: NOT IN (SELECT ...) — perigo de semântica NULL
• MÉDIA: custo de dedup SELECT DISTINCT
• MÉDIA: ORDER BY sem LIMIT ordena o resultado completo

Exemplo 2: Uma consulta limpa e sargable

-- This scores 90+/100 (grade A) — no findings
SELECT id, email, created_at
FROM users
WHERE created_at >= TIMESTAMP '2026-01-01'
  AND created_at <  TIMESTAMP '2026-02-01'
ORDER BY id
LIMIT 100;

As 20 regras (conjunto de regras v1.0.0)

…