anúncios

quarta-feira, 16 de setembro de 2026

Guia prático de economia de tokens com os modelos da OpenAI

Quem utiliza ferramentas de IA integradas como o Codex e os modelos GPT no dia a dia do desenvolvimento de software sabe que a cota de tokens é um recurso sagrado. Em um momento de foco no desenvolvimento, poucas coisas são mais frustrantes do que ser bloqueado por excesso de requisições.

No presente artigo explico os principais insights práticos com 8 estratégias nativas, sem a necessidade de instalar nenhuma extensão ou dependência extra, para fazer sua cota render ao máximo e otimizar o seu fluxo de trabalho.

Cenário e limites da cota

A OpenAI aplica restrições de uso que variam de acordo com o plano contratado. No plano Plus e Business, a cota oscila entre 5 a 45 mensagens/prompts dependendo do consumo e do modelo selecionado. Entender o funcionamento das janelas temporais é essencial para evitar bloqueios inesperados.

8 Estratégias para economizar tokens e elevar a eficiência

1. Gerenciamento das Cotas de Limite (5 Horas vs. Semanal)

Muitos usuários ignoram a existência da janela temporária de 5 horas. Se você estourar essa cota menor durante uma sessão intensa de desenvolvimento, ficará temporariamente bloqueado no Codex, mesmo que ainda possua cota no limite semanal.

  • Administre o ritmo de envios para não travar seu trabalho no meio do expediente.
  • Fique de olho nas mensagens de aviso no painel antes de iniciar tarefas massivas.

2. Escolha o modelo adequado para cada tamanho de tarefa

Utilizar um modelo topo de linha para alterar uma simples cor de texto é a maneira mais rápida de queimar cota. Distribua o trabalho de forma inteligente:

  • Astra: Ideal para investigação de bugs difíceis, problemas desconhecidos e planejamento arquitetural.
  • Sol: Perfeito para a implementação contínua de funcionalidades longas e complexas.
  • Terra: Indicado para alterações rotineiras de código e refatoração leve.
  • Luna: A escolha certa para tarefas pequenas que não afetam regras de negócio (ex: mudar fontes, ajustar títulos e categorizar dados).

3. Teste o Astra em nível baixo (Low) antes do Sol em nível alto (High)

O nível de esforço de raciocínio (effort) impacta diretamente o consumo de tokens. O modo High faz o agente de IA pensar por mais tempo, queimando uma quantidade considerável da cota em cada resposta.

Insight valioso: Em muitos casos práticos, rodar o modelo superior Astra no Low entrega um resultado excelente de primeira, economizando até 5 prompts de um modelo inferior configurado em Sol no High.

4. Cuidado com o modo Fast (Ícone de raio)

Ao contrário de outros agentes de código onde o modo rápido simplifica o raciocínio para gastar menos, no Codex o modo Fast entrega a mesma resposta em menor tempo, mas cobra um custo significativamente maior em tokens.

  • Verifique no painel se o ícone de raio ⚡ Fast está desativado.
  • Mantenha o modo rápido desligado a menos que precise de uma resposta crítica imediatamente.

5. Prompts precisos valem mais do que esforço alto

Aumentar o effort do modelo quando ele erra uma tarefa raramente resolve o problema. Na grande maioria das vezes, o erro acontece porque a IA não tinha informações suficientes.

  • Perca alguns minutos aprimorando a especificação e o contexto no seu prompt.
  • Pergunte ao agente de IA: "Você tem alguma dúvida sobre os requisitos fornecidos?" antes de pedir a execução.
  • Defina uma regra clara de conclusão (Definition of Done), como: "Considere a tarefa concluída apenas se os requisitos foram atentidos e todos os testes unitários passarem e com porcentagem de >=80% de cobertura."

6. Solicite entregas fracionadas e em etapas

Pedir ao agente de IA que desenvolva uma aplicação inteira ou uma funcionalidade gigante de uma só vez satura a janela de contexto e estoura a cota rapidamente, resultando em códigos incompletos e retrabalho.

  • Solicite entregas pequenas e modulares.
  • Testes e aprove cada etapa antes de avançar para a próxima instrução.

7. Utilize arquivos de checkpoint para reiniciar sessões

Sessões muito longas acumulam todo o histórico do chat no contexto de entrada, fazendo com que cada nova mensagem custe milhares de tokens desnecessários.

Para trocar de sessão sem perder o histórico do projeto, siga estes passos:

  • No final da sessão atual, peça: "Crie um arquivo checkpoint.md na raiz com no máximo 20 linhas contendo o que foi concluído, decisões tomadas, comandos de testes e o que falta fazer."
  • Abra uma nova sessão, selecione o modelo desejado e envie: "Leia o arquivo checkpoint.md e execute apenas o requisito [REQUISITO-1.md]."
  • Sempre verifique se a nova sessão não alterou o modelo automaticamente para a opção padrão.

8. Resets manuais nas configurações da conta

Em atualizações de versão de modelos, a OpenAI costuma conceder resets da cota semanal para os usuários.

  • Acesse as opções navegando em Settings > Usage no seu painel.
  • Verifique se há algum botão de reset disponível.
  • Atenção: Guarde o reset para quando a sua cota semanal realmente tiver esgotado. Ativá-lo pela metade fará com que você perca o saldo restante.

Considerações finais

Economizar tokens é uma questão de postura e metodologia. Ao aplicar pequenas mudanças, como configurar corretamente os níveis de esforço, dividir tarefas em etapas e utilizar checkpoints de contexto, você garante uma experiência fluida no desenvolvimento auxiliado por agente de IA, extraindo a máxima performance dos modelos GPT e Codex sem interrupções indesejadas.

Feito!

sexta-feira, 4 de setembro de 2026

O marco que mudou a Inteligência Artificial Generativa

Se você já utilizou o ChatGPT, o Claude, o Gemini ou qualquer outro modelo de linguagem avançado, saiba que toda a tecnologia por trás dessas ferramentas deriva de um único artigo acadêmico publicado em 2017: "Attention Is All You Need".

No presente artigo, vamos desmistificar o resumo completo desse paper revolucionário, entender por que ele foi o divisor de águas no Processamento de Linguagem Natural (PLN) e explorar os componentes fundamentais que tornam a arquitetura Transformer tão poderosa.

O Problema das Redes Recorrentes (RNNs e LSTMs)

Antes do lançamento do artigo, os modelos de IA utilizados para tarefas de linguagem (como tradução automática) baseavam-se primariamente em RNNs (Recurrent Neural Networks) e LSTMs (Long Short-Term Memory).

Essas arquiteturas apresentavam dois grandes gargalos:

  • Processamento Sequencial: O texto precisava ser lido palavra por palavra, em ordem. Isso impedia a paralelização dos cálculos em GPUs, tornando o treinamento extremamente lento.
  • Perda de Contexto Longo: À medida que a distância entre as palavras aumentava, o modelo tendia a "esquecer" informações cruciais do início do texto.

Para resolver essa limitação, os pesquisadores do Google Brain e do Google Research propuseram uma mudança radical: eliminar completamente a recorrência e confiar exclusivamente em um mecanismo de atenção.

O Coração da Arquitetura: Self-Attention (Autoatenção)

O pilar central do artigo é o mecanismo de Scaled Dot-Product Attention. A ideia é calcular o grau de relação entre todas as palavras da frase simultaneamente, independentemente da distância em que estejam uma da outra.

Figura 1: Mecanismo de Scaled Dot-Product Attention e Multi-Head Attention. Fonte: Vaswani et al. (2017).

Como funciona o cálculo com Query (Q), Key (K) e Value (V)?

Para entender a matemática de forma intuitiva, pense no mecanismo de atenção como uma busca em um banco de dados:

  • Query (Q): O que uma palavra específica está "procurando" no restante da frase para entender seu próprio contexto.
  • Key (K): A "etiqueta" de identificação que cada palavra da frase oferece.
  • Value (V): A informação semântica contida na palavra.

A fórmula matemática oficial do Scaled Dot-Product Attention apresentada no artigo é:

Attention(Q, K, V) = softmax( (Q * KT) / sqrt(dk) ) * V

Onde o processo ocorre nas seguintes etapas:

  1. Multiplicação Q * KT: Gera a pontuação de afinidade entre cada par de palavras.
  2. Escala por sqrt(dk): Normaliza os valores dividindo pela raiz quadrada da dimensão das chaves, evitando gradientes excessivamente grandes durante o treinamento.
  3. Função softmax: Converte as pontuações em probabilidades (pesos de atenção que somam 1).
  4. Multiplicação por V: Aplica esses pesos de atenção aos valores semânticos, gerando o vetor final contextualizado.

As Inovações-Chave do Transformer

Figura 2: Arquitetura completa do Transformer (Encoder-Decoder). Fonte: Vaswani et al. (2017).

1. Multi-Head Attention (Atenção Multi-Cabeça)

Em vez de calcular a atenção apenas uma vez, o modelo divide as projeções de Q, K e V em múltiplas "cabeças" (heads). Pressione Ctrl + C ou navegue pelos dados para perceber que isso permite à rede neural prestar atenção em diferentes aspectos da frase simultaneamente (por exemplo, uma cabeça foca em relações gramaticais, enquanto outra foca em entidades ou contexto de longo prazo).

2. Positional Encoding (Codificação Posicional)

Como o Transformer processa todos os tokens de forma paralela, ele perde a noção nativa de ordem no texto. Para resolver isso, os autores adicionaram vetores contendo funções senoidais ao embedding inicial de cada token, injetando a informação da posição relativa de cada palavra.

3. Arquitetura Encoder-Decoder

O modelo original foi projetado para tradução automática, dividindo-se em duas partes:

  • Encoder: Processa e codifica o texto de entrada.
  • Decoder: Gera a saída token por token, utilizando uma variação chamada Masked Multi-Head Attention para garantir que o modelo não acesse os tokens futuros durante a geração.

Considerações finais

O artigo "Attention Is All You Need" não foi apenas uma melhoria incremental; foi a pedra fundamental para toda a era moderna dos Large Language Models (LLMs). Ao abandonar as redes sequenciais e colocar a atenção paralela no centro da arquitetura, os pesquisadores viabilizaram o treinamento de modelos em escala sem precedentes.

Referências

VASWANI, Ashish et al. Attention is all you need. In: Advances in Neural Information Processing Systems (NeurIPS), 30., 2017, Long Beach. Proceedings... Long Beach: NIPS, 2017. p. 5998-6008. Disponível em: <https://arxiv.org/abs/1706.03762>. Acesso em: 04 set. 2026.

Feito!

quarta-feira, 2 de setembro de 2026

Entendendo os algoritmos de ordenação clássicos com Big O

Quantas vezes você já precisou ordenar uma lista de elementos em sua aplicação e simplesmente chamou o método nativo .sort() da linguagem de sua preferência? Seja em JavaScript, Python ou Java, é extremamente comum confiarmos cegamente nessas abstrações no nosso dia a dia de desenvolvimento.

No entanto, você já se perguntou qual algoritmo está rodando por trás dessa instrução e até onde ele continua sendo eficiente? Em um cenário real com milhões de registros, confiar em um método sem conhecer sua complexidade computacional pode ser a diferença entre um sistema performático e um colapso total de processamento.

Exploraremos a teoria, a notação Big O e os pseudocódigos dos principais algoritmos de ordenação: Selection Sort, Quick Sort e Bubble Sort.

1. A Armadilha da Abstração e a Notação Big O

Quando trabalhamos com conjuntos pequenos de dados, como 30 ou 100 itens, quase qualquer algoritmo apresentará um tempo de resposta imperceptível. Porém, a engenharia de software exige que pensemos em grande escala.

Para medir o impacto do volume de dados no tempo de execução, utilizamos a Notação Big O. O termo O(n) indica que o tempo de execução cresce proporcionalmente ao número de elementos n da lista.

Regra importante: Ignorando as Constantes

Na análise assintótica do Big O, as constantes matemáticas são desconsideradas. Por exemplo, um algoritmo que faz O(1/2 * n²) operações é simplificado diretamente para O(n²). Isso acontece porque, quando n chega à casa dos milhões ou bilhões, cortar o tempo pela metade continua deixando o número na mesma ordem de grandeza astronômica.

2. Selection Sort (Ordenação por Seleção)

O Selection Sort é um dos algoritmos mais intuitivos e simples. A lógica consiste em percorrer a lista inteira, encontrar o menor (ou maior) elemento, posicioná-lo no início (ou em uma nova lista) e repetir o processo para os elementos restantes.

Complexidade de Tempo

  • Pior caso: O(n²)
  • Caso médio: O(n²)
  • Melhor caso: O(n²)

Como o algoritmo precisa realizar comparações aninhadas para cada item da lista, seu comportamento é quadrático em todos os cenários.

Pseudocódigo: Selection Sort

Veja a estrutura básica que você pode traduzir para a sua linguagem favorita:

funcao selectionSort(lista)
    n = tamanho(lista)
    
    para i de 0 ate n - 1 faca
        indiceMenor = i
        
        para j de i + 1 ate n - 1 faca
            se lista[j] < lista[indiceMenor] entao
                indiceMenor = j
            fimSe
        fimPara
        
        se indiceMenor != i entao
            trocar(lista[i], lista[indiceMenor])
        fimSe
    fimPara
    
    retornar lista
fimFuncao

3. Quick Sort: A Estratégia Dividir para Conquistar

O Quick Sort é um dos algoritmos de ordenação mais eficientes e utilizados na prática (inclusive compondo bibliotecas padrão de linguagens como C e Java). Ele opera através da estratégia de Dividir para Conquistar utilizando a recursão.

Como Funciona o Quick Sort

  • Caso Base: Listas com 0 ou 1 elemento já estão ordenadas por natureza. A recursão para aqui.
  • Escolha do Pivô: Seleciona-se um elemento da lista para ser a referência (pivô).
  • Particionamento: A lista é dividida em duas sublistas: uma com elementos menores que o pivô e outra com elementos maiores.
  • Recursão e Junção: O Quick Sort é chamado recursivamente para as sublistas, e o resultado final é combinado: [menores] + [pivô] + [maiores].

Complexidade de Tempo

  • Caso médio: O(n log n). O fator log n vem da divisão sucessiva do problema ao meio, enquanto o n deriva do loop de particionamento.
  • Pior caso: O(n²). Ocorre quando a escolha do pivô é ruim (por exemplo, escolher sempre o maior ou menor elemento em uma lista que já está ordenada).

Pseudocódigo: Quick Sort

Abaixo está a implementação conceitual recursiva do Quick Sort:

funcao quickSort(lista)
    se tamanho(lista) < 2 entao
        retornar lista // Caso Base
    fimSe

    pivo = lista[0] // Escolhendo o primeiro elemento como pivô
    menores = listaVazia()
    maiores = listaVazia()

    para cada elemento em lista[1..fim] faca
        se elemento <= pivo entao
            adicionar(menores, elemento)
        senao
            adicionar(maiores, elemento)
        fimSe
    fimPara

    retornar concatenar(quickSort(menores), pivo, quickSort(maiores))
fimFuncao

4. Bubble Sort (Ordenação por Bolha)

O Bubble Sort é frequentemente ensinado em cursos introdutórios. Ele percorre a lista repetidamente, comparando pares de elementos adjacentes e trocando-os de lugar se estiverem na ordem errada. Os maiores elementos "flutuam" para o final da lista como bolhas.

Complexidade de Tempo

  • Pior caso: O(n²)
  • Caso médio: O(n²)
  • Melhor caso: O(n) (quando a lista já está ordenada e há uma flag de controle de trocas).

Pseudocódigo: Bubble Sort

funcao bubbleSort(lista)
    n = tamanho(lista)
    
    para i de 0 ate n - 1 faca
        trocou = falso
        
        para j de 0 ate n - i - 2 faca
            se lista[j] > lista[j + 1] entao
                trocar(lista[j], lista[j + 1])
                trocou = verdadeiro
            fimSe
        fimPara
        
        // Se nenhuma troca ocorreu nesta passagem, a lista ja esta ordenada
        se nao trocou entao
            interromper
        fimSe
    fimPara
    
    retornar lista
fimFuncao

5. Tabela Comparativa de Desempenho

Para visualizar a diferença gritante de escala entre as complexidades de tempo, considere o impacto hipotético na execução ao ordenar um conjunto com 1.000 elementos:

Algoritmo Complexidade (Caso Médio) Complexidade (Pior Caso) Desempenho Estimado (1.000 itens)
Selection Sort O(n²) O(n²) Lento (~27 horas em escala comparativa)
Bubble Sort O(n²) O(n²) Muito Lento (Loops Aninhados)
Quick Sort O(n log n) O(n²) Muito Rápido (~996 segundos na mesma escala)

Considerações finais

Conhecer o que está por trás do método .sort() transforma a forma como escrevemos código. Embora na maioria dos casos as funções nativas sejam extremamente otimizadas, compreender o comportamento do Quick Sort, do Selection Sort e a mecânica das partições e da notação Big O fornece a autonomia necessária para diagnosticar gargalos e tomar decisões arquiteturais corretas ao trabalhar com grandes volumes de dados.

Agora que você possui o pseudocódigo em mãos, escolha a sua linguagem de programação principal (seja JavaScript, Python, C#, Java ou Go) e implemente cada um desses algoritmos para fixar o aprendizado na prática!

Feito!

sexta-feira, 28 de agosto de 2026

Como fazer perguntas certas

No universo do desenvolvimento de software, tecnologias mudam, requisitos evoluem, frameworks e linguagens se transformam. No entanto, uma habilidade permanece atemporal e crucial para a eficiência de qualquer profissional: a capacidade de obter informações precisas rapidamente. E o caminho mais curto para isso é saber fazer as perguntas certas.

O Problema da Pergunta Vaga (e por que ela falha sempre)

O exemplo mais clássico e desastroso de comunicação no dia a dia da tecnologia é a famigerada mensagem: "Oi, o aplicativo está dando erro. Você pode me ajudar?".

O exemplo do aplicativo dar erro, sem dizer qual é o problema ou onde ele ocorre, é típico de pessoas que não sabem se comunicar. Esse tipo de abordagem parte da falsa premissa de que quem vai responder sabe tudo de cabeça ou adivinhará o contexto por telepatia. Na realidade, ninguém sabe tudo; o que profissionais experientes possuem é padrão de reconhecimento acumulado. Quando você fornece a mensagem de erro exata e o contexto, fica exponencialmente mais fácil para quem responde apontar a solução mais provável.

Humano vs. Assistente de IA: A Regra é exatamente a mesma

O mesmo se aplica em como fazer perguntas certas para um humano e para um assistente de IA. Se você fizer essa mesma pergunta ruim de exemplo, nenhum humano e nenhum assistente de IA saberá responder. Já o exemplo de pergunta certa facilita tanto para o humano quanto para o assistente de IA.

A comunicação é importante para saber tirar dúvidas com um dev sênior ou com um assistente de IA, pois se não souber se comunicar bem de forma detalhada, fica difícil ajudar. Enquanto o desenvolvedor sênior perde tempo e contexto tentando extrair informações de você, a IA acabará gerando respostas genéricas, códigos irrelevantes ou alucinações. Em ambos os casos, o princípio de Garbage In, Garbage Out (Entrada ruim, saída ruim) se aplica perfeitamente.

Estrutura de uma pergunta eficiente

Uma boa pergunta economiza tempo e demonstra respeito pelo fluxo de trabalho do outro. Ela deve conter obrigatoriamente:

  • Contexto claro: Qual tarefa, ticket ou projeto você está executando.
  • O erro exato: Mensagem de exceção (ex: NullPointerException), logs relevantes ou comportamento retornado.
  • O que já foi tentado: Hipóteses que você já testou ou verificações que realizou no código.
  • Localização: A classe, endpoint ou função onde o problema ocorre.

O ciclo das 2 horas: Equilíbrio entre autonomia e dependência

Ao buscar suporte técnico, a maioria dos devs cai em dois extremos perigosos: ou passam dias travados sem perguntar nada (prejudicando a deadline e as dailies), ou perguntam a cada pequeno obstáculo sem sequer tentar pesquisar (tornando-se um fardo para a equipe).

Para encontrar o ponto de equilíbrio e manter a produtividade alta, adote a regra do Ciclo de 2 Horas antes de solicitar ajuda:

  • 10 a 15 minutos: Busque por um código parecido ou uma funcionalidade similar dentro do próprio projeto para se basear.
  • 5 a 10 minutos: Consulte a documentação interna/da linguagem ou questione seu assistente de IA preferido.
  • 30 a 70 minutos: Tente implementar e debugar a solução na prática.

Se após esse tempo o problema persistir, é o momento exato de pedir ajuda a um colega, trazendo todo o contexto estruturado do que você aprendeu e testou nessas duas horas.

Exceções ao ciclo de 2 Horas

Existem cenários onde você não deve esperar o ciclo terminar para pedir suporte:

  • Tarefas com deadlines urgentes em ambiente de produção.
  • Devs iniciantes ou recém-chegados que receberam uma demanda crítica por engano.
  • Trabalhos que exigem atuação pareada (pair programming) ou em times globais.

Considerações finais: Documente tudo

Por fim, após resolver qualquer dúvida, seja com a ajuda do seu time ou do assistente de IA, documente tudo o que você aprendeu. Manter um registro simples de soluções serve como base de conhecimento para consultas futuras, ajuda seu "eu do futuro" e contribui para a evolução técnica de toda a equipe.

Saber se comunicar com clareza e fazer as perguntas certas é a ferramenta mais poderosa para acelerar sua carreira e se destacar como um desenvolvedor eficiente.

Feito!

quinta-feira, 27 de agosto de 2026

Meu histórico do git parece um desastre, como eu conserto?

O Problema

Você abriu o git log e encontrou algo assim:

fix stuff
wip
tentativa 2
eslint de novo
bug fix
como assim nao funciona
REVERT
feat: adds feature X (nao funciona ainda)
me ajuda por favor
fix: arruma o fix anterior

Seu histórico está bagunçado, commits inúteis poluem o repositório, e o pior: alguém pode ver isso no pull request.

A Causa

Falta de disciplina com mensagens de commit, commits demais para Changes pequenos, e uso incorreto do git add . commitando tudo junto.

A Solução

1. Reescreva os últimos N commits com rebase interativo

git rebase -i HEAD~5

Isso abre um editor com os últimos 5 commits. Você pode:

pick   abc1234 feat: adiciona login
squash def5678 fix: ajusta layout
squash ghi9012 wip: tentativa 2
pick   jkl3456 feat: adiciona logout

squash combina o commit no anterior. fixup faz o mesmo mas descarta a mensagem.

2. Corrija a última mensagem de commit

git commit --amend -m "feat: adiciona autenticação com JWT"

3. Desfaça o último commit mantendo as mudanças

git reset --soft HEAD~1

As mudanças ficam staged para você reorganizar com git add seletivo.

4. Desfaça completamente o último commit

git reset --hard HEAD~1

Cuidado: isso apaga as mudanças permanentemente.

5. Limpe dados sensíveis já commitados

git filter-branch --force --index-filter \
  'git rm --cached --ignore-unmatch .env' \
  --prune-empty --tag-name-filter cat -- --all

Depois force o push:

git push origin --force --all

6. Organize com staging seletivo

git add -p

Isso abre um modo interativo onde você escolhe pedaços específicos do arquivo para commitar.

Antes vs Depois

Antes Depois
fix stuff feat: adiciona autenticação JWT
wip feat: adiciona tela de login
tentativa 2 fix: ajusta validação do formulário
como assim nao funciona test: adiciona testes unitários
REVERT chore: atualiza dependências

Regra de Ouro

Uma mensagem de commit deve explicar o quê mudou e por quê. Se você não consegue explicar em uma linha, talvez deveria ser dois commits.

Nunca force push em branches compartilhadas sem avisar o time.

Feito!

terça-feira, 25 de agosto de 2026

Por que minha query SQL está demorando 30 segundos?

O Problema

Você tem uma tabela pedidos com milhões de registros e precisa buscar pedidos de um cliente específico. A query simples assim demora uma eternidade:

SELECT * FROM pedidos WHERE cliente_id = 12345;

O MySQL retorna 30 segundos de espera. O PostgreSQL idem. O SQLite? Nem fala.

A Causa

Tabela sem índice na coluna cliente_id. O banco faz Full Table Scan — lendo todos os registros para encontrar os que correspondem ao critério.

A Solução

1. Adicione um índice

CREATE INDEX idx_pedidos_cliente_id ON pedidos(cliente_id);

Resultado: de 30s para 0.003s

2. Use EXPLAIN para analisar

EXPLAIN SELECT * FROM pedidos WHERE cliente_id = 12345;

Veja se o plano mostra Using index (bom) ou Using filesort/Using temporary (ruim).

3. Evite SELECT *

Ruim SELECT * FROM pedidos WHERE cliente_id = 12345; Bom SELECT id, valor, data FROM pedidos WHERE cliente_id = 12345;

4. Verifique os índices existentes

SHOW INDEX FROM pedidos;

5. Use composição de índices quando necessário

-- Para queries que filtram por cliente E data CREATE INDEX idx_pedidos_cliente_data ON pedidos(cliente_id, data DESC);

Resultado Final

Métrica Antes Depois
Tempo de resposta 30s 0.003s
Full Table Scan Sim Não
Uso de memória Alto Baixo

Regra de Ouro

Se uma coluna aparece em WHERE, JOIN ou ORDER BY, considere criar um índice nela.

Índices não são mágicos — eles ocupam espaço em disco. Mas na maioria dos casos, o ganho de performance vale muito mais que o custo de armazenamento.

Feito!

sexta-feira, 21 de agosto de 2026

15 anos de blog

O blog está completando hoje, 21 de Agosto de 2026, 15 anos!

Gostaria de agradecer a todos pelo prestígio e a paciência de ler os posts que são publicados. Espero continuar compartilhando conhecimentos no blog para nossos leitores. Continuem prestigiando e divulgando o blog Mundo da Computação Integral, assim aumentamos nossa comunidade.