O que se segue é simplesmente insano e delirante ...
Se você deixar todos os dados em uma tabela (sem particionamento), você terá tempos de pesquisa de O (log n) usando uma chave. Vamos pegar o pior índice do mundo, a árvore binária. Cada nó da árvore possui exatamente uma chave. Uma árvore binária perfeitamente equilibrada com 268.435.455 (2 ^ 28 - 1) nós de árvore teria uma altura de 28. Se você dividir essa árvore binária em 16 árvores separadas, obterá 16 árvores binárias, cada uma com 16.777.215 (2 ^ 24 - 1) nós da árvore para uma altura de 24. O caminho da pesquisa é reduzido em 4 nós, uma redução de altura de 14,2857%. Se o tempo de pesquisa estiver em microssegundos, uma redução de 14,2857% no tempo de pesquisa será nula a desprezível.
Agora, no mundo real, um índice BTREE teria códigos de árvore com várias chaves. Cada pesquisa BTREE executaria uma pesquisa binária dentro da página, com um possível decente em outra página. Por exemplo, se cada página BTREE contivesse 1024 chaves, uma altura de árvore de 3 ou 4 seria a norma, uma altura de árvore curta.
Observe que o particionamento de uma tabela não reduz a altura do BTREE, que já é pequena. Dado um particionamento de 260 milhões de linhas, existe a forte probabilidade de ter vários BTREEs com a mesma altura. A procura de uma chave pode passar por todas as páginas raiz do BTREE todas as vezes. Somente um cumprirá o caminho do intervalo de pesquisa necessário.
Agora expanda isso. Todas as partições existem na mesma máquina. Se você não tiver discos separados para cada partição, terá E / S de disco e rotações de eixo como um gargalo automático fora do desempenho da pesquisa de partição.
Nesse caso, o pareamento por banco de dados também não comprará nada se id for a única chave de pesquisa sendo usada.
O particionamento de dados deve servir para agrupar dados de maneira lógica e coesa na mesma classe. O desempenho da pesquisa em cada partição não precisa ser a principal consideração, desde que os dados sejam agrupados corretamente. Depois de obter o particionamento lógico, concentre-se no tempo de pesquisa. Se você estiver apenas separando os dados apenas por ID, é possível que muitas linhas de dados nunca sejam acessadas para leituras ou gravações. Agora, isso deve ser uma consideração importante: localize todos os IDs acessados com mais frequência e particione com isso . Todos os IDs acessados com menos frequência devem residir em uma grande tabela de arquivamento que ainda está acessível pela pesquisa de índice para a consulta "uma vez na lua azul".
O impacto geral deve ser ter pelo menos duas partições: uma para os IDs acessados com freqüência e a outra para o restante dos IDs. Se os IDs acessados com frequência forem bastante grandes, você poderá opcionalmente particioná-lo.