Jerarquía de Almacenamiento
El costo de una consulta depende del nivel de almacenamiento donde la base de datos encuentra los datos. Leer de RAM es ~100 000x más rápido que leer de HDD. Una consulta mal escrita puede forzar accesos a niveles lentos innecesariamente.
Niveles de almacenamiento
La base de datos organiza los datos en una jerarquía. Cada nivel sacrifica velocidad por capacidad.
| Nivel | Latencia | Capacidad | Persiste al apagar |
|---|---|---|---|
| CPU / Registros | ~1 ns | Bytes | No |
| Caché (L1/L2/L3) | ~10 ns | KB–MB | No |
| RAM | ~100 ns | GB | No |
| SSD | ~100 μs | GB–TB | Sí |
| HDD | ~10 ms | TB | Sí |
Subir en la jerarquía = más rápido. Bajar = más lento. Menos accesos a disco = mejor rendimiento.
Misma consulta, costo distinto
Una consulta cambia de costo según el nivel donde estén los datos en el momento de ejecutarse.
-- Full Table Scan. LIKE con wildcard inicial inhabilita índices.
SELECT * FROM logs WHERE message LIKE '%error%';
-- Filtro por columna indexada + columnas específicas.
SELECT id, level, message, created_at
FROM logs
WHERE created_at >= '2025-01-01'
AND level = 'ERROR'
ORDER BY created_at;
Problemas del primer query:
LIKE '%...'inhabilita índices → fuerza lectura de cada filaSELECT *incrementa el volumen de datos transferidos entre disco y RAM- Si la tabla no entra completa en memoria, cada lectura requiere acceso a disco
Ventajas del segundo query:
- Filtro indexado sobre
created_at→ lee solo las filas necesarias - Columnas acotadas → menos páginas transferidas
ORDER BYsobre columna indexada → lectura secuencial, evita saltos en disco
Asumir que toda consulta cuesta lo mismo sin considerar si los datos están en RAM o en disco.
RAM vs disco: el balance entre velocidad y capacidad
| Recurso | Ventaja | Desventaja |
|---|---|---|
| RAM | Latencia de nanosegundos | Capacidad limitada, costo elevado |
| Disco | Capacidad abundante, bajo costo | Latencia de microsegundos a milisegundos |
Si una consulta se vuelve lenta sin cambios en datos ni estructura, lo primero es verificar si los datos aún están en memoria.
Casos de aplicación
| Situación | Recomendación |
|---|---|
| Búsqueda frecuente por columna | Crear índice en esa columna |
| Tabla con millones de filas | Preferir columnas específicas sobre SELECT * |
| Consulta que se vuelve lenta sin cambios visibles | Verificar si los datos aún están en memoria |
| Filtro por rango de fechas | Indexar la columna de fecha |
| Mismos datos consultados repetidamente | Ajustar tamaño del buffer pool para retenerlos |