Particionamento no MySQL: quando salva sua vida e quando vira cilada.

Henrique Borba Garcia
13 de fevereiro de 2026
Avançado e Arquitetura

Um assunto bastante comum no MySQL, que divide opiniões é o tal do Particionamento.

Para alguns, a cura em determinados problemas e para outros…. o próprio problema.

Uma afirmação é, particionamento não é performance –> é estratégia.

🧠 O que é o particionamento?

Particionamento é basicamente dividir uma tabela gigantesca em pedaços menores (partições), mas que continuam sendo uma unica só tabela para o MySQL.

Assim, há uma divisão de arquivos físicos diferentes, mas não lógicos.

🍕 A famosa analogia….

Imagine você pedir uma pizza de 16 pedaços.

Sem particionamento = o MySQL precisa procurar a azeitona em todos os pedaços.

Com particionamento = Você fala:

“Eu tenho quase certeza que a azeitona está nos pedaços do lado esquerdo”

E assim, o MySQL buscará somente nesta condição.

Mais rápido, simples e seu SSD agradece.

🟢 Quando o particionamento é seu “Best Friend”.

Use quando você identificar tabelas com valores significativamente grandes.

Quando praticamente para a maiores das consultas forem por RANGE (campos datas).

Sendo necessário manter dados antigos (como um histórico).

Ou até mesmo quando você deseja apagar dados velhos com bastante frequência.

🔴 Quando o particionamento vira CILADA.

Tabelas que possuem volume de dados pequenos.
Queries que não filtram pela coluna da partição, exemplo (select *from VENDAS where cliente_id = 123;)
Joins entre tabelas particionadas por chaves diferentes.

🛠️ Agora vamos a prática…. o primordial de todo conteúdo.

Criando tabela sem partições.

Criando tabela com partições.

Agora, as execuções de buscas (Select’s).

Condições identicas visivelmente para o Dev.

Plano de execução em cada consulta.

Você DBA, deverá ver o retorno do MySQL dizendo que está lendo somente 1 unica partição.

E agora, veremos abaixo o que se torna uma cilada numa tabela particionada que recebe consultas que não utilizam das partições.

MySQL está varrendo todas as partições, a performance aqui…. não há!

O executor sofre, o DBA sofre…. a vida sofre.

🛠️ E para fechar com chave de ouro…. é a manutenção rápida.

A famosa redução de volumetria é essencial para grande parte de ambientes, aqueles dados que não são mais necessário e precisam ser excluídos rapidamente.

Assim, abaixo dois formatos com o mesmo intuito…. porém, usados em cenários com partições e sem partições.

Delete FROM tableName WHERE year(data_venda) = 2023;
Alter Table tableNameParticionada DROP PARTITION p2023;

Enquanto um delete massivo, leverá minutos ou horas…. o DROP PARTITION é quase instantâneo.

🏁 Conclusão… Particionamento é ferramenta, não milagre.

Usem quando ajuda, mas evitem quando atrapalha.

Particionamento é como aquela faca no churrasco….. nas mãos certas faz maravilhas, nas mãos erradas é pronto-socorro 😉😉😉

Dica DBA.

Para certos cenários, poderão utilizar subpartições que facilitaram nas questões de buscas mais seletivas e claram para limpezas especificas.

Assim, para uma partição anual (p2026) poderei adicionar um plano mensal (jan_2026) e assim em diante.

Referências.

https://www.performancedb.com/blog/particionamento-de-tabelas-no-mysql/

https://dev.mysql.com/doc/refman/8.4/en/partitioning-overview.html

COMPARTILHE:

arquitetura, mysql, particionamento, performance

Henrique Borba Garcia

Iniciei meus estudos na área de Desenvolvimento no ano de 2021. Atualmente, em MySQL tenho uma experiência de 5 anos, e com bancos não relacionais (MongoDB) 2 anos. Desempenho o papel de LÍDER TÉCNICO para ambas as técnologias. Sou bastante persistente e proativo em diversos assuntos em banco de dados. Minhas certificações. . MySQL 2025 Solution Enginner Specialist Assessment. . MySQL Database Administrator 8.0 . MySQL Database Developer 8.0 . OCI Foundations 2021, 2022, 2023, e 2024. . MySQL Database Service . MySQL Explorer. . SQL Explorer. . Oracle Cloud Data Management 2023