Diseño y optimización de base de datos

A la mayoría de las bases de datos lentas les falta el índice evidente

Cuando una aplicación se ralentiza a medida que crece, la causa no suele ser el servidor ni el motor de base de datos. Son un puñado de consultas que recorren tablas enteras porque ningún índice coincide con su forma de buscar. Una consulta que tardaba 20 milisegundos con 1.000 filas puede tardar segundos con un millón, y nadie lo nota hasta que lo notan los clientes.

Partimos de la evidencia: las estadísticas de la propia base de datos sobre qué consultas se ejecutan con más frecuencia y tardan más. Eso suele señalar una lista corta de arreglos, como un índice en las columnas que usa un filtro habitual, una consulta reescrita para evitar cargar tablas enteras o un enlace que falta entre tablas y obliga a búsquedas repetidas. Medimos cada consulta antes y después, para que la mejora sea visible y no una afirmación.

Las restricciones frenan los datos erróneos desde el origen

Muchas bases de datos confían en que la aplicación mantenga los datos limpios. La app comprueba que un correo sea único, que un pedido pertenezca a un cliente real, que una cantidad no sea negativa. Luego una segunda app, un script de importación o un arreglo manual con prisas se salta esas comprobaciones, y se cuelan duplicados y registros huérfanos. Los informes empiezan a no cuadrar, y nadie sabe qué cifra es la correcta.

Un esquema bien diseñado impone por sí mismo las reglas importantes: restricciones de unicidad, claves externas, restricciones de comprobación y valores predeterminados sensatos. Todo lo que escriba en la base de datos tiene que cumplirlas. En un sistema existente, localizamos dónde han fallado ya los datos, planificamos la limpieza y después añadimos las restricciones para que no vuelva a ocurrir.

• Restricciones de unicidad en lo que no debe repetirse, como correos electrónicos o números de factura
• Claves foráneas para que los registros no puedan apuntar a algo que no existe
• Restricciones de comprobación para valores que deben mantenerse en rango
• Índices elegidos a partir de patrones de consulta reales, no añadidos por todas partes