¿Por qué NO particionar?

¿Cuándo NO se querría particionar una base de datos? (pensando en particionar MySQL )

En mi caso

• Comenzaré con un par de millones de filas, debería crecer a partir de ahí.
• Clave principal en un campo de caracteres que sirve como la restricción de consulta más frecuente (y las búsquedas son frecuentes, al menos algunas por segundo).
• La clave primaria se codificará para servir como clave de partición
• Se realizarán actualizaciones en cada fila que se extrae en las consultas frecuentes mencionadas anteriormente
• Las búsquedas menos frecuentes (contra columnas de fechas u otras) deberán llegar a todas las particiones

Incluso para el último punto, ¿la búsqueda no se ejecuta en paralelo, así que en todos los casos, es una victoria ? ¿Cuáles son las desventajas de la partición? ¿Por qué no es algo que TODOS usan por defecto, al menos cuando estás viendo más de un millón de registros?

ACTUALIZACIÓN: seleccioné la respuesta de zgguy, pero tenga en cuenta que agregué mi propia respuesta con los resultados de mi propia investigación, incluido un enlace a una respuesta realmente buena sobre una pregunta similar que me fue muy útil.

No hay una bala de plata para los problemas de rendimiento, y la partición tampoco es una.

Cada partición es esencialmente una tabla en sí misma. Por lo tanto, las consultas que se escriben de una manera que permite que la base de datos busque filas en una sola partición se vuelven más rápidas. La diferencia puede ser enorme para las consultas que tendrían que escanear toda la tabla grande, pero pueden limitarse a escanear solo una partición en la tabla particionada. Para búsquedas de teclas únicas, la diferencia es mucho menor.

Sin embargo, las consultas que usan búsquedas de índice de una manera que requiere que la base de datos visite todas o la mayoría de las particiones de tabla (índice) se ejecutarán considerablemente más lentamente.

La ejecución paralela es un tema en sí mismo. Si ejecuta grandes lotes durante la noche y tiene toda la máquina para hacer ese único trabajo, entonces su paralelización es algo bueno. Sin embargo, en un sistema OLTP donde la base de datos atiende constantemente consultas de muchos usuarios concurrentes, no desea que un usuario tome todos los recursos.

La respuesta aquí está bien escrita y presenta argumentos similares a la respuesta de zgguy , que la partición no le ofrece mucho beneficio, si lo hay, a un escenario de una sola máquina donde las búsquedas más frecuentes se basan en la clave principal o algo similar (porque las búsquedas indexadas deberían ser igual de rápidas).

De hecho, un hilo común de consejos parece ser que la razón principal para la partición es tangencial y principalmente relacionada con la administración: por ejemplo, segregue sus datos según la fecha si necesita purgar registros antiguos de vez en cuando. Aunque se observó que esto también puede beneficiar su rendimiento de búsqueda si sus datos son tales que la mayoría de las consultas solo alcanzarán los registros agregados recientemente.

También vi mencionar que MySQL nunca hace nada en paralelo (sería bueno ver algunos enlaces o más explicaciones al respecto).

No he visto a nadie hablar sobre si la actividad de escritura agrega o no consideraciones diferentes.

Lo primero que viene a la mente es la poda de partición ; si eso no es algo que tus consultas puedan usar.

¿Necesitará purgar una gran cantidad de datos de la tabla ya que la partición lo ayudaría? Aunque antiguo, pero esta publicación de Peter tiene pocos puntos a considerar.

y otra cosa que uno puede pensar es la facilidad de uso para tablas simples ... el particionamiento necesita trabajo y mantenimiento adicionales.