\u00a1Esto borra de verdad!<\/strong> Igual con UPDATE, INSERT \u2026 SELECT, etc.<\/p>\n\n\n\nLa forma segura de probar consultas de escritura es:<\/p>\n\n\n\n
BEGIN;\nEXPLAIN ANALYZE DELETE FROM usuarios WHERE email ILIKE '%@prueba.com';\nROLLBACK;<\/code><\/pre>\n\n\n\nSiempre dentro de una transacci\u00f3n que puedas deshacer. Es un h\u00e1bito que te ahorra muchos sustos.<\/p>\n\n\n\n
C\u00f3mo leer el plan sin volverte loco<\/h2>\n\n\n\n
El plan de ejecuci\u00f3n es un \u00e1rbol invertido (se lee de abajo hacia arriba).<\/p>\n\n\n\n
\n- Los nodos de abajo producen filas<\/li>\n\n\n\n
- Los nodos de arriba las consumen \/ filtran \/ ordenan \/ agrupan<\/li>\n\n\n\n
- El nodo de m\u00e1s arriba (el ra\u00edz) muestra el tiempo total real de toda la consulta<\/li>\n<\/ul>\n\n\n\n
Piensa en \u00e9l como una cadena de montaje: si una m\u00e1quina de abajo est\u00e1 lenta, todo el proceso se resiente.<\/p>\n\n\n\n
Los indicadores que realmente importan (m\u00edralos en este orden)<\/h2>\n\n\n\n1. Actual Time –> el que manda<\/h3>\n\n\n\n
Aparece as\u00ed:<\/p>\n\n\n\n
Actual Time=0.015..45.872<\/code><\/pre>\n\n\n\n\n- Primer n\u00famero: tiempo hasta que el nodo empieza a devolver la primera fila<\/li>\n\n\n\n
- Segundo n\u00famero: tiempo total hasta que termina de entregar todas las filas<\/li>\n<\/ul>\n\n\n\n
El segundo valor del nodo ra\u00edz es el tiempo real que tard\u00f3 tu consulta.
Si un nodo intermedio tiene un actual time<\/code> muy alto –> ah\u00ed est\u00e1 casi seguro tu problema.<\/p>\n\n\n\n2. Filas estimadas vs. filas reales (Rows<\/code> vs actual rows<\/code>)<\/h3>\n\n\n\nEjemplo cl\u00e1sico de alarma:<\/p>\n\n\n\n
Rows=10000 (estimated)\nActual rows=12<\/code><\/pre>\n\n\n\nEl planner pens\u00f3 que ibas a sacar 10.000 filas\u2026 y solo salieron 12. Cuando las estimaciones fallan tanto, el plan que elige suele ser p\u00e9simo.<\/p>\n\n\n\n
Causas frecuentes:<\/p>\n\n\n\n
\n- Estad\u00edsticas desactualizadas –>
ANALYZE tabla<\/code>;<\/li>\n\n\n\n- Datos muy sesgados (90% de los valores son \u201cactivo\u201d, pero filtras \u201cinactivo\u201d)<\/li>\n\n\n\n
- Correlaciones entre columnas que el planner no ve<\/li>\n\n\n\n
- Funciones en el
WHERE<\/code> que impiden buenas estimaciones<\/li>\n<\/ul>\n\n\n\nMuchas veces un simple ANALYZE<\/code> arregla el desastre. Otras veces necesitas \u00edndices parciales, estad\u00edsticas extendidas o reescribir el JOIN<\/code>.<\/p>\n\n\n\n3. Buffers \u2013 usa siempre EXPLAIN (ANALYZE, BUFFERS)<\/code><\/h3>\n\n\n\nTe dice si el cuello de botella es I\/O o CPU:<\/p>\n\n\n\n
\nshared hit<\/code> –> la p\u00e1gina ya estaba en memoria (r\u00e1pido)<\/li>\n\n\n\nshared read<\/code> –> tuvo que leer del disco (lento)<\/li>\n\n\n\ntemp read\/write<\/code> –> derram\u00f3 a disco (sorts o hash joins muy grandes)<\/li>\n<\/ul>\n\n\n\nPatrones t\u00edpicos:<\/p>\n\n\n\n
\n- Mucho
shared read <\/code>–> problema de I\/O –> quiz\u00e1s falta \u00edndice o la tabla no cabe en memoria<\/li>\n\n\n\n- Casi todo
hit<\/code> y sigue lento –> CPU, mala estrategia de join, o funciones caras en cada fila<\/li>\n<\/ul>\n\n\n\n4. Loops \u2013 el multiplicador silencioso<\/h3>\n\n\n\nActual rows=1 Loops=45000<\/code><\/pre>\n\n\n\nEsto significa que ese nodo se ejecut\u00f3 45.000 veces. Casi siempre es se\u00f1al de un Nested Loop <\/code>mal elegido (el lado externo produce muchas filas y el interno no tiene \u00edndice r\u00e1pido).<\/p>\n\n\n\nLos tres sospechosos de siempre<\/h2>\n\n\n\nSeq Scan<\/h3>\n\n\n\n
Lee toda la tabla secuencialmente. No es malo por definici\u00f3n<\/strong>. Es la mejor opci\u00f3n si:<\/p>\n\n\n\n\n- Vas a leer gran parte de la tabla<\/li>\n\n\n\n
- La tabla es peque\u00f1a<\/li>\n\n\n\n
- Un \u00edndice ser\u00eda m\u00e1s caro que leer todo<\/li>\n<\/ul>\n\n\n\n
Es sospechoso cuando<\/strong>:<\/p>\n\n\n\n\n- Esperas pocas filas<\/li>\n\n\n\n
- La tabla tiene millones de registros<\/li>\n\n\n\n
- Hay un filtro muy selectivo sin \u00edndice –> ah\u00ed casi siempre es un error<\/li>\n<\/ul>\n\n\n\n
Index Scan vs Bitmap Index Scan<\/h3>\n\n\n\n\n- Index Scan<\/strong> –> perfecto para pocas filas. Va directo al grano.<\/li>\n\n\n\n
- Bitmap Index Scan<\/strong> –> mejor cuando esperas muchas filas dispersas. Construye un mapa en memoria y luego lee bloques completos –> menos saltos aleatorios en disco.<\/li>\n<\/ul>\n\n\n\n
El planner elige seg\u00fan cu\u00e1ntas filas cree que va a devolver.<\/p>\n\n\n\n
Nested Loop<\/h3>\n\n\n\n
Muy com\u00fan en JOINs peque\u00f1os.<\/p>\n\n\n\n
Funciona genial cuando:<\/strong><\/p>\n\n\n\n\n- El lado izquierdo (outer) devuelve pocas filas<\/li>\n\n\n\n
- Hay \u00edndice bueno en la tabla derecha (inner)<\/li>\n<\/ul>\n\n\n\n
Se vuelve pesadilla cuando:<\/strong><\/p>\n\n\n\n\n- El lado outer devuelve miles\/millones de filas<\/li>\n\n\n\n
- No hay \u00edndice en el inner –> se convierte en miles de Seq Scan<\/li>\n\n\n\n
- Loops alt\u00edsimos<\/li>\n<\/ul>\n\n\n\n
Ejemplo real (de los que duelen)<\/h2>\n\n\n\n
Antes \u2013 consulta lenta<\/strong><\/p>\n\n\n\nSeq Scan on transacciones \n (actual time=10.542..120.181 rows=50 loops=1)\n Filter: (monto > 5000)\n Rows Removed by Filter: 999950<\/code><\/pre>\n\n\n\nQu\u00e9 pas\u00f3:<\/p>\n\n\n\n
\n- Ley\u00f3 ~1 mill\u00f3n de filas<\/li>\n\n\n\n
- Descart\u00f3 999.950<\/li>\n\n\n\n
- Solo 50 eran \u00fatiles<\/li>\n\n\n\n
- Much\u00edsimo I\/O in\u00fatil<\/li>\n<\/ul>\n\n\n\n
Despu\u00e9s \u2013 con \u00edndice en monto<\/strong><\/p>\n\n\n\nIndex Scan using idx_transacciones_monto on transacciones \n (actual time=0.048..0.117 rows=50 loops=1)<\/code><\/pre>\n\n\n\nResultado: de ~120 ms –> 0.12 ms<\/p>\n\n\n\n
De buscar una aguja en un pajar –> ir directo a la aguja.<\/p>\n\n\n\n
<\/h2>\n\n\n\n
EXPLAIN ANALYZE<\/code> no opina, no especula, no te vende humo: te muestra lo que de verdad ocurri\u00f3.<\/p>\n\n\n\nCuando una consulta va lenta, la respuesta casi siempre est\u00e1 en uno (o varios) de estos:<\/p>\n\n\n\n
\n- Diferencia grande entre filas estimadas y reales<\/li>\n\n\n\n
- Nodos con
actual time<\/code> muy alto en la mitad del \u00e1rbol<\/li>\n\n\n\n- Muchos
shared read<\/code> o temp write<\/code><\/li>\n\n\n\n- Loops rid\u00edculamente altos<\/li>\n<\/ul>\n\n\n\n
Antes de salir corriendo a crear \u00edndices \u00abpor si acaso\u00bb, mira el plan.<\/p>\n\n\n\n
Muchas veces el problema no es falta de \u00edndice, sino:<\/p>\n\n\n\n
\n- Estad\u00edsticas desactualizadas<\/li>\n\n\n\n
- JOINs mal ordenados<\/li>\n\n\n\n
- Estimaciones de cardinalidad rotas<\/li>\n\n\n\n
- Funciones en columnas que impiden usar \u00edndices<\/li>\n\n\n\n
- Filtros escritos de forma que confunden al planner<\/li>\n<\/ul>\n\n\n\n
Optimizar a ciegas es tirar dados. Optimizar con EXPLAIN ANALYZE<\/code> es ingenier\u00eda de verdad.<\/p>\n\n\n\n\u00bfCu\u00e1l fue la \u00faltima consulta lenta que tuviste? \u00bfYa le pasaste EXPLAIN (ANALYZE, BUFFERS)<\/code>?<\/p>\n\n\n\nPru\u00e9balo hoy mismo en esa query que te tiene pensando como mejorarla\u2026 te sorprender\u00e1 lo que descubres. Sigamos codificando.<\/p>\n","protected":false},"excerpt":{"rendered":"
Si alguna vez has lanzado una consulta y te has quedado mirando la relojito de carga pensando \u201c\u00bfpero por qu\u00e9 tanto?\u201d, es hora de dejar de adivinar. Casi siempre que una query va lenta no es culpa de PostgreSQL. Es que no sabemos qu\u00e9 est\u00e1 haciendo internamente. Y ah\u00ed es donde brilla EXPLAIN ANALYZE. Es […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[18],"tags":[20],"class_list":["post-190","post","type-post","status-publish","format-standard","hentry","category-guia","tag-sql"],"_links":{"self":[{"href":"https:\/\/juredev.com\/blog\/wp-json\/wp\/v2\/posts\/190","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/juredev.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/juredev.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/juredev.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/juredev.com\/blog\/wp-json\/wp\/v2\/comments?post=190"}],"version-history":[{"count":0,"href":"https:\/\/juredev.com\/blog\/wp-json\/wp\/v2\/posts\/190\/revisions"}],"wp:attachment":[{"href":"https:\/\/juredev.com\/blog\/wp-json\/wp\/v2\/media?parent=190"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/juredev.com\/blog\/wp-json\/wp\/v2\/categories?post=190"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/juredev.com\/blog\/wp-json\/wp\/v2\/tags?post=190"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}