Definitivamente comenzará a tener problemas en esa tabla de 42 GB una vez que ya no quepa en la memoria. De hecho, tan pronto como ya no quepa en la memoria, el rendimiento se degradará extremadamente rápido. Una forma de probar es poner esa tabla en otra máquina con menos RAM y ver qué tan mal funciona.
Esto es incorrecto. El particionamiento (ya sea a través de la característica de MySQL 5.1, o de la misma manera usando tablas MERGE) puede proporcionar beneficios de rendimiento significativos incluso si las tablas están en la misma unidad.
Como ejemplo, supongamos que está ejecutando consultas SELECT en su tabla grande usando un rango de fechas. Si la tabla está completa, la consulta se verá obligada a escanear toda la tabla (y con ese tamaño, incluso el uso de índices puede ser lento). La ventaja de particionar es que sus consultas solo se ejecutarán en las particiones donde sea absolutamente necesario. Si cada partición tiene un tamaño de 1 GB y su consulta solo necesita acceder a 5 particiones para completarse, la tabla combinada de 5 GB es mucho más fácil de manejar para MySQL que una versión monstruosa de 42 GB.
Una cosa que debe preguntarse es cómo está consultando los datos. Si existe la posibilidad de que sus consultas solo necesiten acceder a ciertos fragmentos de datos (es decir, un rango de fechas o un rango de ID), la partición de algún tipo resultará beneficiosa.
Escuché que todavía hay algunos errores con el particionado de MySQL 5.1, particularmente relacionados con la elección de la clave correcta por parte de MySQL. Las tablas MERGE pueden proporcionar la misma funcionalidad, aunque requieren un poco más de sobrecarga.
Espero que ayude... ¡buena suerte!
