Eu tenho uma tabela grande (vários 100 milhões de linhas) que gostaria de particionar eficientemente. Minha pergunta é se existe uma troca entre o tamanho da partição e o número de partições. Pelo que entendi, a maioria das consultas em uma coluna usada na partição será mais rápida porque a consulta (para a maioria das consultas) precisará apenas pesquisar na partição aplicável à consulta. Portanto, faria sentido que, para maximizar a eficiência, você devesse dividir uma tabela grande no número máximo de partições, tornando cada partição o menor possível. No caso do MySQL, isso significa 1024 partições. Mas existe alguma desvantagem de desempenho em ter um grande número de partições? Então, como encontrar o número ideal de partições?

Nota: Já existe uma pergunta semelhante no stackoverflow , mas apenas uma resposta, que (da minha perspectiva) erra o alvo. Então, vou declarar a pergunta do meu jeito ... espero que seja mais claro

Vamos compará-los

TAMANHO DA PARTIÇÃO

Se você tem o seguinte:

• 100 milhões de linhas em uma tabela
• Indexação BTREE
• Cada página do BTREE possui 1024 teclas

Como seriam as métricas?

Como LOG (100000000) / LOG (2) = 26.575424759099, um índice BTREE com 1024 chaves por modo de árvore de página teria uma altura de árvore de apenas 3 (CEILING (LOG (100000000) / LOG (1024))). Com apenas três nós de páginas, uma pesquisa binária da chave necessária em cada código de árvore acessado resultaria em uma remoção e isolamento de cerca de 30 chaves.

NÚMERO DE PARTIÇÕES

Se você tem o seguinte:

• 100 milhões de linhas em uma tabela
• Indexação BTREE
• Cada página do BTREE possui 1024 teclas
• Você cria 1024 paritições

Os números seriam ligeiramente diferentes.

Cada partição deve ter cerca de 97656 linhas. Quais seriam as métricas agora?

Como LOG (97656) / LOG (2) = 16.575421065795, um índice BTREE com 1024 chaves por modo de árvore de página teria uma altura de árvore de apenas 2 (CEILING (LOG (97656) / LOG (1024))). Com apenas dois nós de páginas, uma pesquisa binária da chave necessária em cada código de árvore acessado resultaria em uma remoção e isolamento de cerca de 20 chaves.

CONCLUSÃO

A distribuição das chaves apenas remove um nível de árvore, mas cria essencialmente 1024 índices. As consultas não saberão a diferença. O tempo de pesquisa provavelmente seria nominal, na melhor das hipóteses, a favor das partições. No entanto, verifique se todos os dados estão ativos. Além disso, você pode estar atingindo apenas algumas partições, enquanto outras partições com dados raramente acessados ​​apenas ocupam espaço e nunca são acessadas com frequência suficiente para justificar o particionamento . Você pode ter métricas de desempenho diferentes para se preocupar, que são mais flagrantes (como desfragmentação interna no XFS , ext3 x ​​ext4 etc.) Você também precisa se preocupar com o mecanismo de armazenamento que está usando, porque:

• A indexação do InnoDB seria um pouco mais confusa em comparação com o MyISAM, devido à necessidade de gerenciar um índice em cluster
• O InnoDB duplica a gravação de dados no ibdata1, bem como no arquivo de log atual (ib_logfile0 ou ib_logfile1)