Metodo de diagnostico
Proceso para aislar una causa de lentitud antes de cambiar SQL, warehouse u optimizaciones de almacenamiento.
Conceptos que debes poder reconocer y distinguir:
- Query history
- Datos escaneados
- Pruning
- Queueing
- Spilling
- Diagnostico antes de cambiar SQL o warehouse
Usa los enlaces oficiales de Snowflake de esta unidad para ampliar cada concepto y contrastar su comportamiento.
Subir el tamano de un warehouse sin diagnostico puede ocultar el problema y aumentar el coste. El metodo recomendado separa cuatro preguntas: si la query espera en cola, si ejecuta un plan costoso, si escanea mas datos de los necesarios y si el recurso elegido encaja con la concurrencia.
Orden de investigacion
| Paso | Que observar | Accion posible |
|---|---|---|
| 1. Confirmar sintoma | Duracion, frecuencia, warehouse y usuarios afectados | Comparar con una linea base o ejecuciones similares |
| 2. Separar espera de ejecucion | Queued, compilation y execution time | Resolver concurrencia antes de reescribir SQL |
| 3. Leer el perfil | Bytes scanned, spills, joins y operadores | Ajustar filtros, cardinalidad o tamanos |
| 4. Revisar patron | Repeticion, selectividad y volumen | Elegir optimizacion solo si el coste se justifica |
| 5. Verificar despues | Misma query hash o caso comparable | Medir mejora y coste, no solo una ejecucion |
Principios de decision
- Una query en cola no se arregla necesariamente con un indice o una clustering key; primero revisa capacidad y concurrencia.
- Una query que hace remote spill puede requerir menos cardinalidad intermedia, mas memoria o ambos.
- Un escaneo grande no siempre es un problema: importa la selectividad, el tiempo y la frecuencia.
- No pruebes rendimiento con result cache reutilizado si quieres medir ejecucion real.