Olá, Tamires! Como vai?

Agradeço a sua sugestão! Aplicar boas práticas, visando o desempenho das consultas, é algo que também considero necessário. Reforço que na programação existem muitas maneiras de resolver um mesmo problema, eu acho isso fascinante! E o exercício também visa essa reflexão. Logo, o gabarito da pessoa instrutora pode divergir das soluções realizadas pelos estudantes, algo compreensível desde que atinjam um mesmo resultado.

E falando um pouco mais sobre otimização, uma maneira de analisar o desempenho de uma query é usando o comando EXPLAIN, que ajuda você a enxergar como o banco monta e executa uma consulta, mostrando detalhes como: uso de índices, quantidade de dados lidos e operações adicionais realizadas. Para usar o EXPLAIN, basta adicioná-lo antes de uma consulta, exemplo:

EXPLAIN SELECT c.nome, p.data_pedido, p.valor
FROM clientes c
JOIN pedidos p ON c.id = p.cliente_id
WHERE c.cidade = 'São Paulo';

E que tal ver isso na prática? Vamos criar um cenário para isso:

CREATE DATABASE cadastro;

USE cadastro;

CREATE TABLE clientes (
    id INT AUTO_INCREMENT PRIMARY KEY,
    nome VARCHAR(100),
    cidade VARCHAR(100)
);

CREATE TABLE pedidos (
    id INT AUTO_INCREMENT PRIMARY KEY,
    cliente_id INT,
    data_pedido DATE,
    valor DECIMAL(10, 2),
    FOREIGN KEY (cliente_id) REFERENCES clientes(id)
);

INSERT INTO clientes (nome, cidade) VALUES
('João', 'São Paulo'),
('Maria', 'Rio de Janeiro'),
('Carlos', 'Belo Horizonte');

INSERT INTO pedidos (cliente_id, data_pedido, valor) VALUES
(1, '2025-01-01', 100.00),
(1, '2025-02-01', 150.00),
(2, '2025-01-15', 200.00),
(3, '2025-03-01', 250.00);

EXPLAIN SELECT c.nome, p.data_pedido, p.valor
FROM clientes c
JOIN pedidos p ON c.id = p.cliente_id
WHERE c.cidade = 'São Paulo';

Abaixo você pode ver o resultado dessa execução.

Resultado:

Deixo aqui o significado de cada coluna na tabela também:

Sabendo disso, vamos aproveitar e analisar algumas informações.

Análise:

1 type: ALL

• Nos indica que a consulta está fazendo um full table scan. Ou seja, lendo todas as 3 linhas.

2 key: NULL

• Apesar do índice PRIMARY, ele não está sendo usado. Então, uma possível melhoria seria criar um índice em cidade:

  CREATE INDEX idx_cidade ON clientes(cidade);
  

3 type: ALL

• Também nos indica um full table scan em todos os 4 registros.

4 key: NULL

• Mesmo tendo o cliente_id em possible_keys, nenhum índice foi usado. Uma melhoria seria garantir que cliente_id tenha índice:

  CREATE INDEX idx_cliente_id ON pedidos(cliente_id);
  

5 Extra: Using join buffer (flat, BNL join)

• Indica um Block Nested Loop (BNL) Join , o que é menos eficiente, pois está carregando os dados em memória para comparar. Uma melhoria seria garantir que a relação esteja bem otimizada: índices nos campos de junção, chave estrangeira bem definida, filtros aplicados antes do JOIN e uma consulta mais enxuta (sem excesso de colunas).

Aplicando esse tipo de conhecimento, a gente garante um desempenho melhor nas consultas. Isso impacta e muito em situações de larga escala com milhares de dados sendo consultados em tempo real, como no caso de aplicações de redes sociais, por exemplo: Instagram, X e Facebook.

Fico à disposição!

Conte com o apoio da comunidade Alura na sua jornada. Abraços e bons estudos!