Lo siguiente es simplemente una locura despotricando ...
Si deja todos los datos en una tabla (sin particiones), tendrá tiempos de búsqueda O (log n) usando una clave. Tomemos el peor índice del mundo, el árbol binario. Cada nodo de árbol tiene exactamente una clave. Un árbol binario perfectamente equilibrado con 268,435,455 (2 ^ 28 - 1) nodos de árbol tendría una altura de 28. Si divide este árbol binario en 16 árboles separados, obtendrá 16 árboles binarios cada uno con 16,777,215 (2 ^ 24 - 1) nodos de árbol para una altura de 24. La ruta de búsqueda se reduce en 4 nodos, un 14,2857% de reducción de altura. Si el tiempo de búsqueda es en microsegundos, una reducción del 14.2857% en el tiempo de búsqueda es nula a insignificante.
Ahora en el mundo real, un índice BTREE tendría treenodes con múltiples claves. Cada búsqueda BTREE realizaría una búsqueda binaria dentro de la página con un posible descenso a otra página. Por ejemplo, si cada página BTREE contenía 1024 claves, una altura de árbol de 3 o 4 sería la norma, una altura de árbol corta de hecho.
Observe que una partición de una tabla no reduce la altura del BTREE, que ya es pequeña. Dada una partición de 260 millones de filas, incluso existe la gran probabilidad de tener múltiples BTREE con la misma altura. La búsqueda de una clave puede pasar por todas las páginas raíz de BTREE cada vez. Solo uno cumplirá el camino del rango de búsqueda necesario.
Ahora amplíe esto. Todas las particiones existen en la misma máquina. Si no tiene discos separados para cada partición, tendrá E / S de disco y rotaciones de husillo como un cuello de botella automático fuera del rendimiento de búsqueda de la partición.
En este caso, el particionamiento por base de datos tampoco le compra nada si id es la única clave de búsqueda que se está utilizando.
El particionamiento de datos debe servir para agrupar datos que están de manera lógica y coherente en la misma clase. El rendimiento de la búsqueda en cada partición no necesita ser la consideración principal siempre que los datos estén agrupados correctamente. Una vez que haya logrado la partición lógica, concéntrese en el tiempo de búsqueda. Si solo está separando datos por ID solamente, es posible que nunca se pueda acceder a muchas filas de datos para lecturas o escrituras. Ahora, eso debería ser una consideración importante: ubique todos los identificadores a los que se accede con mayor frecuencia y particione con ellos . Todos los ID a los que se accede con menos frecuencia deben residir en una gran tabla de archivo a la que todavía se pueda acceder mediante la búsqueda de índice para esa consulta 'una vez en una luna azul'.
El impacto general debería ser tener al menos dos particiones: una para los identificadores de acceso frecuente y la otra paritiion para el resto de los identificadores. Si los ID a los que se accede con frecuencia son bastante grandes, opcionalmente podría particionarlos.