Cuando la base crece
Lo que funciona con mil filas y falla con medio millón: consultas que recorren todo, listas sin paginar, y el índice que faltaba. Cómo se diagnostica sin adivinar.
Ver qué hace una consulta
SQLite puede explicar cómo va a resolver una consulta, y es la herramienta que convierte la adivinación en diagnóstico:
EXPLAIN QUERY PLANSELECT * FROM evento WHERE proyecto_id = 42 ORDER BY en DESC LIMIT 50;Lo que hay que buscar en la respuesta es una palabra: si dice que recorre la tabla entera, falta un índice. Si dice que usa un índice, va bien.
Con eso se diagnostica el 80% de los casos, y merece hacerlo con las cinco o seis consultas principales de tu aplicación sobre una base grande, no sobre la tuya de doscientas filas — porque con doscientas filas recorrer entero también es instantáneo y no se nota nada.
Las tres causas
Paginar bien
La segunda causa se arregla paginando, y hay dos formas — una de las cuales se degrada con el tamaño:
Para una lista que se desplaza, cursor. Para una tabla con números de página, desplazamiento — que en escritorio es menos frecuente de lo que parece.
Probar con volumen
La costumbre que evita todo esto, y cuesta media hora montarla una vez:
// una función de desarrollo que llena la base con datos realistas#[cfg(debug_assertions)]pub fn generar_datos_de_prueba(conn: &Connection, proyectos: u32, eventos_por: u32) -> Result<()> { let tx = conn.unchecked_transaction()?; // nivel 41.4: sin esto tarda horas // … generar … tx.commit()}Con eso puedes tener en un minuto la base que un usuario tendrá en tres años, y probar contra ella. Es la diferencia entre descubrir un problema de rendimiento tú o que te lo cuente alguien.
Y merece que los datos sean realistas en forma, no solo en cantidad: si en producción hay un proyecto con diez mil elementos y el resto con veinte, generar cien proyectos de cien elementos cada uno no reproduce el caso que va a doler.