Una vez trabajé con una base de datos MySQL muy grande (Terabyte+). La tabla más grande que teníamos tenía literalmente más de mil millones de filas.
Funcionó. MySQL procesó los datos correctamente la mayor parte del tiempo. Sin embargo, era extremadamente difícil de manejar.
Solo hacer una copia de seguridad y almacenar los datos fue un desafío. Llevaría días restaurar la mesa si fuera necesario.
Teníamos numerosas mesas en el rango de 10 a 100 millones de filas. Cualquier unión significativa a las tablas requería demasiado tiempo y llevaría una eternidad. Así que escribimos procedimientos almacenados para 'recorrer' las tablas y procesar uniones contra rangos de 'id's. De esta manera, procesaríamos los datos de 10 a 100 000 filas a la vez (Únete a los ID 1 a 100 000 y luego a 100 001 a 200 000, etc.). Esto fue significativamente más rápido que unirse contra toda la mesa.
El uso de índices en tablas muy grandes que no se basan en la clave principal también es mucho más difícil. Mysql almacena índices en dos partes:almacena índices (aparte del índice principal) como índices de los valores de clave principal. Entonces, las búsquedas indexadas se realizan en dos partes:Primero, MySQL va a un índice y extrae de él los valores de clave principal que necesita encontrar, luego realiza una segunda búsqueda en el índice de clave principal para encontrar dónde están esos valores.
La red de esto es que para tablas muy grandes (1-200 millones más filas) la indexación contra tablas es más restrictiva. Necesita menos índices más simples. E incluso hacer declaraciones de selección simples que no están directamente en un índice puede nunca volver. Donde las cláusulas deben accede a los índices u olvídalo.
Pero dicho todo esto, las cosas realmente funcionaron. Pudimos usar MySQL con estas tablas muy grandes y hacer cálculos y obtener respuestas correctas.
