Percona Server for MySQL 9.7 ganha DISTANCE() para similaridade vetorial nativa
O fork da Percona implementa DISTANCE() e VECTOR_DISTANCE() com cinco métricas e SIMD adaptativo, trazendo ao MySQL aberto um recurso hoje restrito ao HeatWave da Oracle na OCI.
A Percona lançou no Percona Server for MySQL↳MySQL8 conteúdosMySQL + Adminer + Docker Compose: montando rapidamente um ambiente para usoData · abr 2019Banco de dados MYSQL no PHPStormDev (Back & Front) · jul 2019Criando um ambiente de desenvolvimento PHP mínimo com Docker – Parte 3Dev (Back & Front) · out 2019Ver tudo em Data → 9.7.2-2 as funções DISTANCE() e VECTOR_DISTANCE(), que calculam similaridade entre vetores diretamente em SQL. O anúncio, publicado no blog da empresa, fecha uma lacuna incômoda: o MySQL já tinha o tipo VECTOR (com TO_VECTOR() e FROM_VECTOR()) desde a versão 9.7, mas faltava a peça que transforma uma coluna de embeddings em algo consultável por proximidade. Sem essa função, o desenvolvedor guardava embeddings no MySQL e precisava de outro sistema, um vector DB dedicado como Pinecone, Qdrant ou pgvector no Postgres, só para fazer a busca por similaridade.
O que exatamente foi adicionado
DISTANCE(vetor1, vetor2, metrica) recebe dois valores do tipo VECTOR (ou literais convertidos via TO_VECTOR()) e uma métrica fixa em string, e devolve um DOUBLE com o escore de distância. VECTOR_DISTANCE() é apenas um sinônimo, com comportamento idêntico. As métricas suportadas são cinco: EUCLIDEAN, EUCLIDEAN_SQUARED, MANHATTAN, COSINE e DOT. Isso já é mais do que o próprio MySQL nativo oferece: a implementação da Oracle, disponível apenas no HeatWave MySQL rodando na OCI, cobre só COSINE, DOT e EUCLIDEAN, e não existe nem na versão Community nem na Commercial do MySQL padrão. A Percona está, na prática, trazendo para qualquer infraestrutura, on-premises, outra nuvem, bare metal, um recurso que hoje é vendor lock-in de uma única plataforma.
Duas dessas métricas merecem atenção de quem já trabalha com embeddings de produção. EUCLIDEAN_SQUARED produz o mesmo ranking que EUCLIDEAN, mas pula a raiz quadrada, útil em ORDER BY quando só a posição relativa importa, não o valor absoluto. E o DOT inverte a convenção usual do produto interno: como a indústria tende a multiplicar por -1 e inverter a escala, aqui valores menores também significam maior similaridade, mantendo consistência com as outras quatro métricas. Vale ler a documentação com atenção antes de escolher: a métrica certa depende de como o modelo de embeddings foi treinado. A maioria dos modelos modernos, casos de OpenAI e Cohere, foi treinada com similaridade de cosseno, então COSINE é o padrão seguro. Se o vetor carrega informação de magnitude, como em features numéricas não normalizadas, EUCLIDEAN costuma ser mais apropriada.
Exemplo de uso
O fluxo típico começa com uma tabela que já guarda o embedding ao lado dos dados relacionais:
CREATE TABLE products (
id INT PRIMARY KEY,
name VARCHAR(255),
embedding VECTOR(1536)
);
INSERT INTO products VALUES
(1, 'Product A', TO_VECTOR('[0.1, 0.2, 0.3, ...]')),
(2, 'Product B', TO_VECTOR('[0.15, 0.25, 0.35, ...]'));A consulta por similaridade fica embutida no SELECT, sem chamada externa a nenhum outro serviço:
SELECT id, name,
DISTANCE(embedding, TO_VECTOR('[0.12, 0.22, 0.32, ...]'), 'EUCLIDEAN') AS score
FROM products
ORDER BY score
LIMIT 5;O resultado ordena pelo escore, do mais próximo ao mais distante. É o tipo de query que hoje um time de RAG↳RAG6 conteúdosTécnica RAG com a biblioteca Langchain: tutorial para aplicar agoraData · jun 2024Como avaliar LLMs, RAG e Agentes de IA: Teoria e prática.AI · abr 2026RAG Não É Memória: O Problema Real dos Agentes de IAAI · mai 2026Ver tudo em AI → (retrieval-augmented generation) monta contra um vector DB separado, apenas para recuperar os chunks de texto mais relevantes antes de mandar o prompt para o modelo de linguagem. Com DISTANCE(), essa recuperação acontece no mesmo banco relacional que já guarda produto, usuário, pedido ou o que for, o que elimina uma sincronização de dados entre dois sistemas e simplifica o desenho de arquitetura para quem está começando a colocar busca semântica em produção.
SIMD sob o capô
A parte de engenharia mais interessante do anúncio é como a Percona conseguiu desempenho aceitável sem ainda ter índice de busca aproximada. A implementação detecta em tempo de startup o conjunto de instruções SIMD disponível na CPU, e escolhe o melhor tier automaticamente: SSE4.2 em x86_64 ou NEON em aarch64 dão de 2x a 3x sobre execução escalar; AVX2 chega a 4x-6x; AVX-512F, quando disponível, promete de 8x a 12x; e SVE2 cobre ARM com vetores de largura escalável. Isso evita compilar um binário fixo por arquitetura de destino (a abordagem -march=native), o que seria inviável para um produto distribuído em múltiplas plataformas. Vetores pequenos, com menos de 16 dimensões, usam o tier de 128 bits porque o custo de montar registradores maiores supera o ganho; vetores grandes, como os 1536 dimensões do exemplo do OpenAI, usam automaticamente o tier mais largo disponível. Os kernels também usam sempre leitura não alinhada de memória, porque colunas VECTOR não têm garantia de alinhamento de cache line e CPUs modernas não penalizam esse tipo de acesso quando o dado já está em cache.
O que ainda falta: sem índice, é full table scan
Aqui está o ponto que separa entusiasmo de uso responsável em produção. DISTANCE() é uma função escalar: ela calcula a distância entre dois vetores e devolve um número, ponto. Uma query como ORDER BY DISTANCE(...) LIMIT k sobre uma tabela grande roda em O(n): o banco chama a função para cada linha e depois ordena. É exata e acelerada por SIMD por linha, mas não escala como um índice HNSW (Hierarchical Navigable Small World) ou IVF (Inverted File) escalaria. A própria Percona é direta sobre isso no anúncio: falta ANN indexing, e é o próximo item do roadmap. Sem índice de busca aproximada, encontrar os 10 vizinhos mais próximos em uma tabela de 1 milhão de vetores significa varrer o milhão de linhas a cada consulta, algo que fica caro rápido conforme a tabela cresce.
Quando vale a pena usar isso agora
Para catálogos pequenos ou médios, algumas dezenas de milhares de linhas, DISTANCE() já resolve busca semântica sem trazer outro sistema para a arquitetura, e ainda entrega resultado exato, não aproximado, o que pode ser preferível em domínios onde precisão importa mais que velocidade bruta. Para bases de milhões de embeddings com exigência de latência de milissegundos, ainda falta a peça de indexação: um vector DB dedicado ou o HeatWave da Oracle (que já tem ANN) continuam sendo a escolha mais sensata até a Percona entregar HNSW ou IVF no Server for MySQL. Vale acompanhar o roadmap: a empresa pede explicitamente feedback sobre quais estratégias de índice e integrações de modelo de embeddings priorizar, então o recurso deve evoluir rápido nas próximas versões.
Fonte: Percona Database Blog
Este artigo foi escrito por Roberto Diniz, colunista de banco de dados. Conteúdo produzido por agente de IA da redação iMasters, sob revisão editorial humana. Saiba como produzimos no expediente.
Especialista virtual de banco de dados e engenharia de dados. DBA veterano, TI tradicional: modelagem, performance de query, integridade e governança. Formal e criterioso — desconfia de modinha e preza consistência, backup e o plano de execução.
