SQL de verdade: quando banco de dados deixou de ser só 'onde ficam os dados'
Na Oi eu sabia que banco de dados existia. Na pesquisa, aprendi a usar SQL de verdade — JOINs, GROUP BY, subqueries. E entendi que dado é mais do que armazenamento.
A query que travou o banco levou 40 segundos para retornar.
Não era banco de produção — era banco de pesquisa com uns 200 mil registros. Mas 40 segundos para uma query que eu achava simples foi suficiente para entender que SQL não é só "buscar dado". É um sistema de execução com custo.
EXPLAIN virou meu melhor amigo naquela tarde.
Na Oi, banco de dados existia como componente de sistema. Eu sabia que Active Directory tinha base de dados por baixo. Sabia que o servidor de email usava armazenamento estruturado. Mas nunca escrevi uma query. Nunca pensei em dado como objeto de trabalho — era infraestrutura que acontecia por baixo do que eu operava.
Na pesquisa, dado era o trabalho.
Precisava cruzar tabelas, agregar por categoria, filtrar por período, identificar padrão. A primeira vez que escrevi um JOIN de verdade — não copiado de tutorial, mas construído para responder uma pergunta específica que eu tinha — foi diferente. Era raciocínio sobre relacionamento entre entidades, não só busca.
O que SQL ensina que nenhuma outra ferramenta ensina da mesma forma:
Pensar em conjuntos, não em loops. A maioria das linguagens de programação pensa em "para cada item, faça X." SQL pensa em "para o conjunto que satisfaz essa condição, retorne isso." Desenvolver o instinto de conjunto em vez de iteração muda como você modela problema.
Relacionamento entre entidades é design. A forma como você normaliza o esquema determina quais queries são simples e quais são caras. Dado mal modelado é débito técnico que você paga em toda query.
Query tem custo. Sem índice na coluna do WHERE, o banco varre a tabela inteira. JOIN sem índice escala mal. Subquery que referencia tabela grande dentro de loop é N+1 antes de você saber o nome do problema.
O N+1 eu descobri sem saber o nome.
Tinha um loop em Python que, para cada registro da lista, fazia uma query separada para buscar detalhe relacionado. Funcionava com 100 registros. Com 10 mil, travou. Olhei o log do banco: 10 mil queries individuais onde poderia ter sido uma com JOIN.
Aprendi o padrão errado antes de aprender o nome. Quando vi "N+1 problem" documentado pela primeira vez em artigo de Rails, reconheci imediatamente o que tinha feito.
Essa experiência com SQL moldou como penso em acesso a dado até hoje. Quando reviso código que usa ORM, a primeira pergunta é "quantas queries isso gera?" Quando vejo loop com chamada de banco dentro, sei o que vai acontecer quando a tabela crescer.
O instinto não veio de documentação. Veio de ter travado um banco de pesquisa com uma query ingênua e ter passado uma tarde entendendo por quê.
Essa semana: pega uma query que você usa frequentemente e roda EXPLAIN. Você consegue interpretar o plano de execução?