Ce qui suit est juste fou furieux et délirant ...
Si vous laissez toutes les données dans une table (pas de partitionnement), vous aurez des temps de recherche O (log n) à l'aide d'une clé. Prenons le pire indice du monde, l'arbre binaire. Chaque nœud d'arbre a exactement une clé. Un arbre binaire parfaitement équilibré avec 268 435 455 (2 ^ 28 - 1) nœuds d'arbre aurait une hauteur de 28. Si vous divisez cet arbre binaire en 16 arbres distincts, vous obtenez 16 arbres binaires chacun avec 16 777 215 (2 ^ 24 - 1) nœuds d'arbre pour une hauteur de 24. Le chemin de recherche est réduit de 4 nœuds, soit une réduction de hauteur de 14,2857%. Si le temps de recherche est en microsecondes, une réduction de 14,2857% du temps de recherche est nulle à négligeable.
Maintenant dans le monde réel, un index BTREE aurait des treenodes avec plusieurs clés. Chaque recherche BTREE effectuerait une recherche binaire dans la page avec un décent possible dans une autre page. Par exemple, si chaque page BTREE contenait 1024 clés, une hauteur d'arbre de 3 ou 4 serait la norme, une hauteur d'arbre courte en effet.
Notez qu'un partitionnement d'une table ne réduit pas la hauteur du BTREE qui est déjà petit. Étant donné un partitionnement de 260 milliions de lignes, il existe même une forte probabilité d'avoir plusieurs BTREE avec la même hauteur. La recherche d'une clé peut passer à travers toutes les pages BTREE racine à chaque fois. Un seul remplira le chemin de la plage de recherche nécessaire.
Développez maintenant ceci. Toutes les partitions existent sur la même machine. Si vous n'avez pas de disques séparés pour chaque partition, vous aurez des E / S de disque et des rotations de broches comme goulot d'étranglement automatique en dehors des performances de recherche de partition.
Dans ce cas, le partitionnement par base de données ne vous rapporte rien non plus si id est la seule clé de recherche utilisée.
Le partitionnement des données doit servir à regrouper les données qui sont logiquement et cohérentes dans la même classe. Les performances de recherche de chaque partition ne doivent pas être la principale considération tant que les données sont correctement regroupées. Une fois que vous avez atteint le partitionnement logique, concentrez-vous sur le temps de recherche. Si vous séparez simplement les données par identifiant uniquement, il est possible que de nombreuses lignes de données ne soient jamais accessibles en lecture ou en écriture. Maintenant, cela devrait être une considération majeure: localisez tous les identifiants les plus fréquemment consultés et partitionnez en conséquence . Tous les identifiants moins fréquemment utilisés doivent résider dans une grande table d'archives qui est toujours accessible par la recherche d'index pour cette requête "une fois dans une lune bleue".
L'impact global devrait être d'avoir au moins deux partitions: une pour les identifiants fréquemment utilisés et l'autre parité pour les autres identifiants. Si les identifiants fréquemment utilisés sont assez volumineux, vous pouvez éventuellement le partitionner.