SQRT no SQL: raiz quadrada, distancia euclidiana e desvio padrao

SQRT retorna a raiz quadrada de um numero: um bloco classico para geometria, estatistica e qualquer formula com uma "raiz de uma soma de quadrados". No PostgreSQL e uma funcao comum, mas tem algumas arestas — a entrada negativa e a escolha de tipo — em que e facil tropecar em producao.

Sintaxe basica e tipos

O caso mais simples e a raiz de uma constante:

SELECT SQRT(144);   -- 12
SELECT SQRT(2);     -- 1.4142135623730951

SQRT recebe double precision e retorna double precision. Se voce passar um numeric, o PostgreSQL escolhe a sobrecarga numeric e retorna numeric — exato, porem mais lento:

SELECT SQRT(2::numeric);  -- 1.4142135623730950488...
SELECT pg_typeof(SQRT(2::numeric));  -- numeric
SELECT pg_typeof(SQRT(2::double precision));  -- double precision

• Para dinheiro em orders.amount (normalmente numeric), a raiz ja fica em numeric sozinha.
• Para analise pesada sobre milhoes de linhas, converter para double precision e bem mais rapido.

O erro com entrada negativa

A raiz de um numero negativo nao e definida nos reais, entao o PostgreSQL nao retorna NULL: ele lanca um erro:

SELECT SQRT(-1);
-- ERROR: cannot take square root of a negative number

Isso significa que uma unica linha "ruim" pode derrubar a consulta inteira. Se sua entrada pode ficar negativa (por exemplo, uma diferenca de magnitudes), pegue o valor absoluto de forma explicita:

SELECT SQRT(ABS(balance))    AS magnitude,
       SIGN(balance)         AS direction
FROM (SELECT amount - 100 AS balance FROM orders) t;

• Garanta o sinal de antemao: ABS(x) ou power(x, 2) antes da raiz.
• Uma entrada NULL gera uma saida NULL — isso nao e um erro, ao contrario de um numero negativo.

Pegadinha: no MySQL, SQRT(-1) retorna NULL em vez de falhar, e o ClickHouse retorna nan. A mesma consulta se comporta de modo diferente entre os motores, e um NULL/nan silencioso pode corromper agregacoes seguintes antes de voce perceber.

Distancia euclidiana

O uso classico e a distancia entre dois pontos via teorema de Pitagoras: SQRT(dx^2 + dy^2). Suponha que os usuarios carregam coordenadas lat/lon e queremos os proximos de um escritorio:

SELECT id,
       name,
       SQRT(power(lat - 40.0, 2) + power(lon - (-3.7), 2)) AS dist
FROM users
ORDER BY dist
LIMIT 10;

Para apenas ordenar por proximidade voce nao precisa da raiz — a distancia ao quadrado e monotona:

SELECT id, name
FROM users
ORDER BY power(lat - 40.0, 2) + power(lon - (-3.7), 2)
LIMIT 10;

• Omita SQRT quando quiser a ordem, nao o numero em si: menos trabalho de CPU.
• O PostgreSQL tambem tem ^ para potencia (x ^ 2), mas power(x, 2) se le com menos ambiguidade.

Desvio padrao na mao

O PostgreSQL traz stddev_pop e stddev_samp, mas vale saber montar a variancia voce mesmo: e SQRT(AVG(x^2) - AVG(x)^2). Vamos medir a dispersao salarial por departamento:

SELECT dept,
       SQRT(AVG(power(salary, 2)) - power(AVG(salary), 2)) AS std_pop,
       stddev_pop(salary)                                  AS std_check
FROM employees
GROUP BY dept;

As colunas std_pop e std_check vao coincidir. A formula manual mostra exatamente de onde vem a raiz, e ela se transfere para uma janela:

SELECT id,
       salary,
       SQRT(
         AVG(power(salary, 2)) OVER w
         - power(AVG(salary) OVER w, 2)
       ) AS dept_std
FROM employees
WINDOW w AS (PARTITION BY dept);

• Em double precision, a formula AVG(x^2) - AVG(x)^2 pode dar um valor negativo minusculo por erro de arredondamento — e entao SQRT falha. Envolva como SQRT(GREATEST(variance, 0)).
• Para relatorios financeiros, calcule em numeric: mais lento, mas sem surpresas de arredondamento.

Conclusao

SQRT e simples mas exige disciplina: proteja a entrada negativa com ABS/GREATEST, escolha numeric versus double precision com criterio e omita a raiz quando so a ordem importa. Assim geometria e estatistica no SQL continuam rapidas e previsiveis.