Pedidos lentos en el admin de WooCommerce: encuentra consultas pesadas y acelera

Guía rápida de diagnóstico

Cuando la pantalla de Pedidos en el admin está lenta, quieres un ciclo cerrado: reproducir, medir, identificar la consulta más lenta,
y entonces decidir si arreglas la forma de los datos, los índices, la caché o el comportamiento de un plugin. Aquí está el orden
de operaciones que encuentra el cuello de botella rápido.

Primero: confirma dónde se va el tiempo

• Waterfall del navegador / TTFB: Si Time To First Byte es enorme, es del lado del servidor. Si TTFB está bien pero el renderizado tarda, es JS front-end o una carga HTML enorme.
• PHP-FPM slowlog: Si los workers PHP están bloqueados en llamadas a BD, lo verás. Si están bloqueados en llamadas HTTP, también lo verás.
• Base de datos: Busca tiempo de consulta largo, bloqueos o filas examinadas masivas.

Segundo: captura la peor consulta, no todas las consultas

• MySQL slow query log (temporal, dirigido) para capturar endpoints de admin.
• Performance Schema para ordenar las sentencias por tiempo total.
• Query Monitor (si puedes instalar) para ver la consulta exacta y la pila de llamadas.

Tercero: decide la clase de arreglo

• Índice faltante/ineficaz: Añade un índice compuesto, o deja de hacer escaneos no indexados de meta.
• Explosión de joins de meta: Reduce filtros, reescribe con mejores claves, o migra a HPOS.
• Inflación por plugins: Desactiva funciones que añaden joins/columnas a la lista de Pedidos; arregla patrones N+1.
• Contención: Bloqueos por importaciones/webhooks/cron; agenda y procesa en lotes.
• Ausencia/mal uso de caché: Añade caché de objetos, pero no intentes caché para tapar un escaneo de tabla completo.

El objetivo no es “hacerlo más rápido” en abstracto. El objetivo es convertir la página de Pedidos de una granja de consultas en una búsqueda
predecible e indexada. Eso significa menos filas examinadas, menos joins y menos sorpresas.

Hechos y contexto interesantes (por qué esto ocurre)

Algo de contexto te ayuda a dejar de pelear la guerra anterior. Los problemas de rendimiento del admin de WooCommerce no son nuevos ni aleatorios.
Aquí hay hechos concretos que explican los patrones que verás.

1. El modelo original “todo es un post” de WordPress hizo que productos y pedidos encajaran en wp_posts, pero también empujó datos estructurados a wp_postmeta, una tabla que envejece mal a escala.
2. Las tablas de meta son tipo EAV (entity-attribute-value). Geniales para flexibilidad, mediocres para filtrar y ordenar, y realmente malas cuando se combinan múltiples claves meta en una sola consulta.
3. WooCommerce históricamente guardó datos de pedidos en posts/postmeta, por eso filtrar pedidos por estado, fecha, total, método de pago o campos de cliente a menudo significa joins contra wp_postmeta.
4. Los índices secundarios de InnoDB no almacenan la fila completa. Almacenan las columnas indexadas más la clave primaria. Si la consulta necesita más campos, puede implicar más lecturas de página.
5. “Filas examinadas” suele ser el verdadero villano. Una consulta de 200 ms que examina 20 millones de filas es una interrupción de producción esperando más tráfico.
6. HPOS (High-Performance Order Storage) de WooCommerce existe en gran parte porque wp_posts/wp_postmeta no podían escalar para tiendas con muchos pedidos sin patrones de consulta dolorosos.
7. MySQL no puede usar eficientemente dos índices separados para algunos patrones multicondición como la gente desearía. Los índices compuestos suelen vencer al optimismo de “añadí un índice a cada columna”.
8. Las páginas de admin son privilegiadas y pesadas—calculan agregados, cargan objetos relacionados y ejecutan comprobaciones de capacidades. Estás benchmarkeando un autobús, no una bicicleta.
9. COUNT(*) puede ser caro en InnoDB porque no mantiene un conteo de filas barato como otros motores. Las listas de pedidos que calculan totales por estado pueden ser costosas.

Si extraes una sola cosa de la lección histórica: la lentitud del admin de WooCommerce suele ser un problema de diseño de datos disfrazado de problema PHP.

Qué significa realmente “Pedidos lento” en producción

“Pedidos lento” puede ser al menos cinco modos de fallo diferentes. Trátalos de forma distinta.

Modo de fallo A: TTFB largo y luego la página carga

El servidor está haciendo trabajo antes de enviar HTML. Normalmente consultas MySQL, a veces llamadas remotas (tarifas de envío, estado de pago),
y ocasionalmente grafos de objetos PHP masivos.

Modo de fallo B: la página carga, pero la tabla de Pedidos queda vacía por un rato

A menudo componentes impulsados por AJAX, endpoints REST, o fetches en background de la tabla de lista.
Revisa tiempos de admin-ajax y REST, no solo la petición principal.

Modo de fallo C: timeouts intermitentes

Contención clásica. Un job cron, importación, tormenta de webhooks o backup se solapan con uso del admin.
O estás saturando workers PHP-FPM y las peticiones del admin esperan hasta morir.

Modo de fallo D: solo algunos usuarios lo ven

Los roles importan. Algunos plugins añaden columnas/acciones solo para administradores, o cargan integraciones adicionales
para capacidades específicas de usuario. Además, las opciones de pantalla por usuario pueden cambiar el tamaño de la lista.

Modo de fallo E: va rápido en staging, lento en prod

Staging tiene 2.000 pedidos. Producción tiene 2.000.000 filas en postmeta. Felicidades, has descubierto la escala.

Broma #1: Si tu página de Pedidos solo se ralentiza durante grandes ventas, no es “misterioso”: es tu base de datos pidiendo una tregua.

Instrumentación que dice la verdad (no sensaciones)

No puedes optimizar lo que no puedes observar. Pero tampoco puedes observarlo todo sin causar nuevos problemas.
El truco es añadir visibilidad dirigida para endpoints de admin y quitarla una vez que tengas la evidencia.

Elige tu herramienta según las restricciones

• Seguro en producción, baja sobrecarga: MySQL slow query log (con umbrales sensatos), resúmenes digest de Performance Schema, PHP-FPM slowlog.
• Más detalle, más riesgo: Plugin Query Monitor en producción (a veces ok, a menudo no), general query log completo (casi nunca).
• Mejor de ambos mundos si lo tienes: APM tracing (New Relic, Datadog, etc.). Pero aún necesitas entender SQL.

Una cita para mantenerte honesto

La esperanza no es una estrategia. — General Gordon R. Sullivan

En este contexto: no “esperes” que añadir Redis arregle una consulta que escanea toda la tabla meta.
Mide primero. Luego arregla la cosa específica que está lenta.

Tareas prácticas: comandos, salidas, decisiones

Estas son tareas reales que puedes ejecutar en un stack típico Linux + Nginx/Apache + PHP-FPM + MySQL/MariaDB.
Cada tarea incluye: comando, salida de ejemplo, lo que significa y qué decisión tomar.
Ejecútalas en este orden si estás apagando fuegos.

Tarea 1: Confirma el endpoint lento y tiempos desde access logs

cr0x@server:~$ sudo awk '$7 ~ /wp-admin\/edit.php/ && $0 ~ /post_type=shop_order/ {print $4,$7,$9,$10,$NF}' /var/log/nginx/access.log | tail -n 5
[27/Dec/2025:11:04:11 /wp-admin/edit.php?post_type=shop_order 200 81234 6.982
[27/Dec/2025:11:04:29 /wp-admin/edit.php?post_type=shop_order 200 80991 7.104
[27/Dec/2025:11:05:02 /wp-admin/edit.php?post_type=shop_order 504 0 30.001
[27/Dec/2025:11:05:45 /wp-admin/edit.php?post_type=shop_order 200 81012 8.331
[27/Dec/2025:11:06:13 /wp-admin/edit.php?post_type=shop_order 200 81120 7.955

Qué significa: Las solicitudes de la lista de Pedidos están tardando 7–8 segundos, con ocasionales 504 a 30 segundos (timeout del proxy).

Decisión: Trata esto como latencia del lado del servidor. Pasa a inspección de PHP-FPM y BD, no a ajustes front-end.

Tarea 2: Revisa saturación de PHP-FPM (el encolamiento parece “lentitud aleatoria”)

cr0x@server:~$ sudo ss -s
Total: 2181
TCP:   1612 (estab 204, closed 1298, orphaned 0, timewait 120)

Transport Total     IP        IPv6
RAW       0         0         0
UDP       9         7         2
TCP       314       247       67
INET      323       254       69
FRAG      0         0         0

Qué significa: No es definitivo, pero una pila de conexiones puede indicar backlog. Necesitas status de PHP-FPM.

Decisión: Si no tienes PHP-FPM status habilitado, actívalo (temporal, con control de acceso). Luego inspecciona workers activos/idle.

Tarea 3: Lee el estado del pool PHP-FPM (activos vs max children)

cr0x@server:~$ curl -s http://127.0.0.1/status?full | egrep -i 'active processes|max active processes|idle processes|max children reached|slow requests'
active processes: 24
max active processes: 24
idle processes: 0
max children reached: 93
slow requests: 117

Qué significa: Estás al máximo de children con cero procesos idle; las peticiones están encolándose. El sistema está sobrecargado o bloqueado.

Decisión: No solo subas pm.max_children. Encuentra qué está bloqueando a los workers (a menudo llamadas a BD). Pasa al slowlog y BD.

Tarea 4: Activa PHP-FPM slowlog por una ventana corta

cr0x@server:~$ sudo grep -nE 'slowlog|request_slowlog_timeout' /etc/php/8.2/fpm/pool.d/www.conf
255:;slowlog = /var/log/php8.2-fpm/slow.log
256:;request_slowlog_timeout = 5s

cr0x@server:~$ sudo sed -i 's#^;slowlog =.*#slowlog = /var/log/php8.2-fpm/slow.log#; s#^;request_slowlog_timeout =.*#request_slowlog_timeout = 5s#' /etc/php/8.2/fpm/pool.d/www.conf
cr0x@server:~$ sudo systemctl reload php8.2-fpm

Qué significa: Las peticiones que tarden más de 5 segundos vuelcan una traza de pila.

Decisión: Reproduce la carga lenta de Pedidos una o dos veces, luego inspecciona el slow log y desactívalo si es demasiado ruidoso.

Tarea 5: Inspecciona el PHP-FPM slowlog para ver dónde se pasa el tiempo

cr0x@server:~$ sudo tail -n 30 /var/log/php8.2-fpm/slow.log
[27-Dec-2025 11:07:44]  [pool www] pid 22144
script_filename = /var/www/html/wp-admin/edit.php
[0x00007f1c2b9d0a80] mysqli_query() /var/www/html/wp-includes/wp-db.php:2351
[0x00007f1c2b9d0a10] _do_query() /var/www/html/wp-includes/wp-db.php:2265
[0x00007f1c2b9d08b0] query() /var/www/html/wp-includes/wp-db.php:3132
[0x00007f1c2b9d06e0] get_results() /var/www/html/wp-includes/wp-db.php:3645
[0x00007f1c2b9d05d0] query() /var/www/html/wp-content/plugins/woocommerce/includes/data-stores/class-wc-order-data-store-cpt.php:...

Qué significa: Los workers están bloqueados en MySQL. Ahora necesitas el SQL exacto y su plan.

Decisión: Habilita el slow query log de MySQL o usa Performance Schema para capturar la sentencia específica.

Tarea 6: Activa MySQL slow query log de forma segura (temporal, con umbral)

cr0x@server:~$ mysql -uroot -p -e "SHOW VARIABLES LIKE 'slow_query_log'; SHOW VARIABLES LIKE 'long_query_time'; SHOW VARIABLES LIKE 'slow_query_log_file';"
Enter password:
+----------------+-------+
| Variable_name  | Value |
+----------------+-------+
| slow_query_log | OFF   |
+----------------+-------+
+-----------------+-------+
| Variable_name   | Value |
+-----------------+-------+
| long_query_time | 10.000|
+-----------------+-------+
+---------------------+-------------------------------+
| Variable_name       | Value                         |
+---------------------+-------------------------------+
| slow_query_log_file | /var/log/mysql/mysql-slow.log |
+---------------------+-------------------------------+

cr0x@server:~$ mysql -uroot -p -e "SET GLOBAL slow_query_log = 'ON'; SET GLOBAL long_query_time = 1; SET GLOBAL log_queries_not_using_indexes = 'ON';"
Enter password:

Qué significa: Las consultas más lentas de 1 segundo (y las que no usan índices) serán registradas. Es suficiente para capturar la lentitud del admin sin inundar.

Decisión: Reproduce la carga de la página Pedidos. Luego analiza el slow log y desactiva si el volumen de logs es alto.

Tarea 7: Encuentra las peores consultas del admin de WooCommerce en el slow log

cr0x@server:~$ sudo pt-query-digest /var/log/mysql/mysql-slow.log | sed -n '1,120p'
#  1.2s user time, 40ms system time, 27.43M rss, 1.18G vsz
# Current date: Fri Dec 27 11:10:01 2025
# Overall: 193 total, 19 unique, 0.03 QPS, 0.21x concurrency _____________
# Time range: 2025-12-27T11:06:11 to 2025-12-27T11:09:55
# Attribute          total     min     max     avg     95%  stddev  median
# ============     ======= ======= ======= ======= ======= ======= =======
# Query time        301.2s   0.002s  28.991s   1.561s   6.821s   3.102s   0.912s
# Rows examined     1.62G       10  38.12M   8.39M  22.01M   9.11M   6.33M
# Profile
# Rank Query ID                      Response time Calls R/Call  V/M   Item
# ==== ============================= ============= ===== ======= ===== ============
#    1 0x7A2F1F8E3C2B4A1D            172.2330  41  4.2008  0.80  SELECT wp_posts ...
#    2 0x9B1A0E21FF77C0B4             68.1192  22  3.0963  0.62  SELECT wp_postmeta ...

Qué significa: Filas examinadas masivas. Esto no es un problema de “PHP lento”. Es acceso a datos.

Decisión: Extrae la huella de la consulta superior y ejecuta EXPLAIN/EXPLAIN ANALYZE. Buscas escaneos completos, orden de joins malo y uso de temp tables/filesort.

Tarea 8: Extrae la muestra de la consulta exacta y ejecuta EXPLAIN

cr0x@server:~$ sudo grep -n "SELECT .*wp_posts" -m 1 -A 20 /var/log/mysql/mysql-slow.log | sed -n '1,25p'
# Time: 2025-12-27T11:08:12.123456Z
# Query_time: 6.821  Lock_time: 0.002 Rows_sent: 25  Rows_examined: 22010431
SET timestamp=1766833692;
SELECT SQL_CALC_FOUND_ROWS  wp_posts.ID
FROM wp_posts
LEFT JOIN wp_postmeta ON ( wp_posts.ID = wp_postmeta.post_id )
WHERE 1=1
AND ( wp_postmeta.meta_key = '_billing_email' AND wp_postmeta.meta_value LIKE '%@example.com%' )
AND wp_posts.post_type = 'shop_order'
ORDER BY wp_posts.post_date DESC
LIMIT 0, 25;

cr0x@server:~$ mysql -uroot -p wordpress -e "EXPLAIN SELECT wp_posts.ID FROM wp_posts LEFT JOIN wp_postmeta ON ( wp_posts.ID = wp_postmeta.post_id ) WHERE ( wp_postmeta.meta_key = '_billing_email' AND wp_postmeta.meta_value LIKE '%@example.com%' ) AND wp_posts.post_type = 'shop_order' ORDER BY wp_posts.post_date DESC LIMIT 0,25\G"
Enter password:
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: wp_postmeta
   partitions: NULL
         type: ref
possible_keys: post_id,meta_key
          key: meta_key
      key_len: 191
          ref: const
         rows: 4821031
     filtered: 10.00
        Extra: Using where; Using temporary; Using filesort
*************************** 2. row ***************************
           id: 1
  select_type: SIMPLE
        table: wp_posts
         type: eq_ref
possible_keys: PRIMARY,type_status_date
          key: PRIMARY
      key_len: 8
          ref: wordpress.wp_postmeta.post_id
         rows: 1
        Extra: Using where

Qué significa: MySQL parte de wp_postmeta usando meta_key, luego escanea millones de filas para aplicar el filtro LIKE.
“Using temporary; Using filesort” indica trabajo extra para ordenar.

Decisión: Deja de hacer búsquedas wildcard LIKE en meta_value a escala, o añade una estrategia: búsquedas de coincidencia exacta, tablas de búsqueda normalizadas o HPOS. Si debes soportar búsqueda por email, usa patrones anclados al inicio o una columna/tabla indexada dedicada.

Tarea 9: Revisa índices existentes en wp_postmeta (y si ayudan)

cr0x@server:~$ mysql -uroot -p wordpress -e "SHOW INDEX FROM wp_postmeta;"
Enter password:
+------------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+---------+------------+
| Table      | Non_unique | Key_name  | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment | Index_comment | Visible | Expression |
+------------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+---------+------------+
| wp_postmeta|          0 | PRIMARY   |            1 | meta_id     | A         |     98122312|     NULL | NULL   |      | BTREE      |         |               | YES     | NULL       |
| wp_postmeta|          1 | post_id   |            1 | post_id     | A         |     33511291|     NULL | NULL   |      | BTREE      |         |               | YES     | NULL       |
| wp_postmeta|          1 | meta_key  |            1 | meta_key    | A         |        2412 |      191 | NULL   | YES  | BTREE      |         |               | YES     | NULL       |
+------------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+---------+------------+

Qué significa: Existen índices por defecto, pero no hay un índice compuesto como (meta_key, meta_value) o (meta_key, post_id) que ayude a patrones específicos.

Decisión: No añadas a ciegas (meta_key, meta_value) porque meta_value es longtext y indexarlo requiere prefijo y pensamiento cuidadoso. Prefiere arreglar el patrón de consulta (evita LIKE con wildcard) o migrar a HPOS. Si añades índices, añade el compuesto más pequeño y selectivo que coincida con tu WHERE y join.

Tarea 10: Revisa el volumen de pedidos y bloat de postmeta (la escala importa)

cr0x@server:~$ mysql -uroot -p wordpress -e "SELECT COUNT(*) AS orders FROM wp_posts WHERE post_type='shop_order'; SELECT COUNT(*) AS order_meta_rows FROM wp_postmeta pm JOIN wp_posts p ON p.ID=pm.post_id WHERE p.post_type='shop_order';"
Enter password:
+--------+
| orders |
+--------+
| 218942 |
+--------+
+-----------------+
| order_meta_rows |
+-----------------+
| 18320177        |
+-----------------+

Qué significa: ~219k pedidos pero ~18M filas meta para pedidos. No es raro, pero explica por qué filtrar por meta duele.

Decisión: Si aún usas almacenamiento legacy, considera seriamente HPOS por rendimiento. Si no puedes, restringe la búsqueda del admin y arregla los principales patrones de consulta.

Tarea 11: Ver los principales digests SQL por tiempo total (Performance Schema)

cr0x@server:~$ mysql -uroot -p -e "SELECT DIGEST_TEXT, COUNT_STAR, SUM_TIMER_WAIT/1000000000000 AS total_sec, AVG_TIMER_WAIT/1000000000000 AS avg_sec, SUM_ROWS_EXAMINED FROM performance_schema.events_statements_summary_by_digest ORDER BY SUM_TIMER_WAIT DESC LIMIT 3\G"
Enter password:
*************************** 1. row ***************************
DIGEST_TEXT: SELECT SQL_CALC_FOUND_ROWS `wp_posts`.`ID` FROM `wp_posts` LEFT JOIN `wp_postmeta` ON ( `wp_posts`.`ID` = `wp_postmeta`.`post_id` ) WHERE ...
 COUNT_STAR: 97
 total_sec: 214.731
   avg_sec: 2.214
SUM_ROWS_EXAMINED: 913200112
*************************** 2. row ***************************
DIGEST_TEXT: SELECT `meta_id`, `post_id`, `meta_key`, `meta_value` FROM `wp_postmeta` WHERE `post_id` IN ( ... )
 COUNT_STAR: 412
 total_sec: 71.334
   avg_sec: 0.173
SUM_ROWS_EXAMINED: 18445022

Qué significa: La sentencia más pesada es el patrón de consulta de la lista de Pedidos. La segunda es un patrón de fetch de meta que puede ser un variante N+1.

Decisión: Optimiza el digest #1 primero. Si arreglas el patrón #1, normalmente mejoras la percepción de “el admin está lento”.

Tarea 12: Revisa contención de locks alrededor de tablas de pedidos

cr0x@server:~$ mysql -uroot -p -e "SHOW ENGINE INNODB STATUS\G" | egrep -n 'LATEST DETECTED DEADLOCK|TRANSACTIONS|LOCK WAIT|wait' | head -n 40
Enter password:
72:TRANSACTIONS
85:---TRANSACTION 93488322, ACTIVE 18 sec starting index read
86:mysql tables in use 1, locked 1
87:LOCK WAIT 3 lock struct(s), heap size 1136, 2 row lock(s)
88:MySQL thread id 221, OS thread handle 140067524396800, query id 9123219 10.0.2.14 wordpress updating

Qué significa: Hay transacciones esperando locks. Esto puede convertir “lentitud ocasional” en “inutilizable aleatorio”.

Decisión: Identifica la consulta que bloquea (PROCESSLIST), luego decide: reduce el alcance de la transacción, procesa en lotes, mueve importaciones fuera de pico, o ajusta aislamiento/bloqueo cuando corresponda.

Tarea 13: Identifica la consulta bloqueadora en vivo

cr0x@server:~$ mysql -uroot -p -e "SHOW FULL PROCESSLIST;" | head -n 15
Enter password:
+-----+---------+-----------+-----------+---------+------+------------------------+------------------------------+
| Id  | User    | Host      | db        | Command | Time | State                  | Info                         |
+-----+---------+-----------+-----------+---------+------+------------------------+------------------------------+
| 221 | wp_user | 10.0.2.14 | wordpress | Query   |   18 | updating               | UPDATE wp_postmeta SET ...   |
| 227 | wp_user | 10.0.2.19 | wordpress | Query   |    7 | Sending data           | SELECT SQL_CALC_FOUND_ROWS...|
| 229 | wp_user | 10.0.2.19 | wordpress | Query   |    6 | Waiting for table lock | SELECT ... wp_postmeta ...   |
+-----+---------+-----------+-----------+---------+------+------------------------+------------------------------+

Qué significa: Un UPDATE está ejecutándose largo y causando esperas. El SELECT de Pedidos sufre daño colateral.

Decisión: Si el UPDATE viene de un plugin que hace cambios masivos en meta, limítalo, pártelo en lotes o muévelo a una cola. No permitas que trabajos “background” compitan con flujos del admin en horas pico.

Tarea 14: Revisa buffer pool de InnoDB y si estás limitado por disco

cr0x@server:~$ mysql -uroot -p -e "SHOW VARIABLES LIKE 'innodb_buffer_pool_size'; SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_reads'; SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_read_requests';"
Enter password:
+-------------------------+------------+
| Variable_name           | Value      |
+-------------------------+------------+
| innodb_buffer_pool_size | 2147483648 |
+-------------------------+------------+
+--------------------------+--------+
| Variable_name            | Value  |
+--------------------------+--------+
| Innodb_buffer_pool_reads | 918221 |
+--------------------------+--------+
+--------------------------------+-----------+
| Variable_name                  | Value     |
+--------------------------------+-----------+
| Innodb_buffer_pool_read_requests | 918221223 |
+--------------------------------+-----------+

Qué significa: 2 GB de buffer pool es pequeño para una tienda WooCommerce ocupada con millones de filas meta. Las lecturas desde disco son no triviales.

Decisión: Si el host DB tiene RAM, aumenta el buffer pool (con cuidado). Pero hazlo después de arreglar las peores consultas; si no, solo estás cacheando mal comportamiento.

Tarea 15: Verifica presencia y tasa de aciertos de caché de objetos (ejemplo Redis)

cr0x@server:~$ redis-cli INFO stats | egrep 'keyspace_hits|keyspace_misses'
keyspace_hits:18382122
keyspace_misses:8821331

Qué significa: La tasa de aciertos es aproximadamente 67%. No es terrible, pero tampoco excelente. Las páginas de admin pueden seguir fallando si las claves no son persistentes o los TTL son cortos.

Decisión: Asegura que un drop-in de caché de objetos persistente esté activo y no deshabilitado para admin. Pero no persigas 99% de aciertos como religión; arregla la SQL peor primero.

Tarea 16: Perfila hooks de WordPress y llamadas lentas con WP-CLI (sospechosos: plugins)

cr0x@server:~$ wp --path=/var/www/html --allow-root plugin list --status=active
+-------------------------------+--------+-----------+---------+
| name                          | status | update    | version |
+-------------------------------+--------+-----------+---------+
| woocommerce                   | active | available | 8.8.3   |
| woocommerce-subscriptions     | active | none      | 6.6.0   |
| some-order-exporter           | active | none      | 2.1.4   |
| query-monitor                 | inactive | none    | 3.15.0  |
+-------------------------------+--------+-----------+---------+

Qué significa: Tienes algunos “modificadores” probables de la lista de Pedidos (exportadores, subscriptions, CRMs) que a menudo añaden joins/columnas.

Decisión: Prueba desactivar sospechosos en staging, o en producción durante una ventana controlada, y mide tiempo de carga de Pedidos y slow queries otra vez.

Tarea 17: Mide tiempo de respuesta desde el servidor (curl como chequeo de realidad)

cr0x@server:~$ curl -s -o /dev/null -w "ttfb=%{time_starttransfer} total=%{time_total} code=%{http_code}\n" -H "Cookie: wordpress_logged_in_x=REDACTED" "https://shop.example.com/wp-admin/edit.php?post_type=shop_order"
ttfb=6.742 total=7.118 code=200

Qué significa: TTFB es la mayor parte del total, confirmando el cuello de botella del servidor.

Decisión: Sigue enfocándote en BD/PHP, no en minificar assets del admin.

Tarea 18: Observa latencia de disco (porque las bases de datos odian almacenamiento lento)

cr0x@server:~$ iostat -x 1 5
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           9.02    0.00    3.11    8.44    0.00   79.43

Device            r/s     w/s   rkB/s   wkB/s  avgrq-sz avgqu-sz   await  r_await  w_await  svctm  %util
nvme0n1         210.0    95.0  8420.0  6120.0     68.0     4.20   14.80    18.90     5.10   0.55  16.8

Qué significa: 8% iowait y ~19 ms read await pueden amplificar planes de consulta malos. No es catastrófico, pero tampoco gratis.

Decisión: Si arreglas consultas y aún ves await alto bajo carga admin, considera mejoras de almacenamiento o aislar I/O de la BD de vecinos ruidosos.

Tarea 19: Deshacer la instrumentación temporal (sé buen ciudadano)

cr0x@server:~$ mysql -uroot -p -e "SET GLOBAL slow_query_log='OFF'; SET GLOBAL long_query_time=10; SET GLOBAL log_queries_not_using_indexes='OFF';"
Enter password:

Qué significa: Has capturado evidencia y reducido la sobrecarga continua.

Decisión: Mantén un registro escrito de los digests y planes principales. La optimización sin notas es cómo los equipos retroceden seis meses después.

Patrones comunes de consultas pesadas en el admin de WooCommerce

Una vez que tengas muestras de queries lentas y salida de EXPLAIN, empezarás a ver repeticiones. La lentitud del admin de WooCommerce suele ser
solo tres o cuatro patrones con diferentes parámetros.

Patrón 1: Filtrado por meta con LIKE en meta_value

Buscar pedidos por email, nombre, dirección o cualquier cosa almacenada en postmeta tiende a hacer:
filtrar por meta_key y luego escanear muchas filas para aplicar LIKE '%...%'. Ese wildcard inicial mata la utilidad del índice.

Pista de diagnóstico: EXPLAIN arranca en wp_postmeta, alto “rows”, “Using temporary; Using filesort”.

Dirección de corrección: Cambia el comportamiento de búsqueda (coincidencia exacta / empieza-con), usa HPOS, o añade tablas de búsqueda indexadas dedicadas. Indexar con prefijo en longtext es un parche parcial y arriesgado.

Patrón 2: ORDER BY post_date con WHERE amplio, causando filesort

La lista de Pedidos usa ordenamiento (fecha, total, estado) y paginación. Si MySQL no puede satisfacer ORDER BY desde un índice,
ordena muchos candidatos y luego devuelve 25.

Pista de diagnóstico: “Using filesort” y filas examinadas enormes.

Dirección de corrección: Mejora selectividad, añade índices compuestos que coincidan con WHERE + ORDER BY, o cambia el modelo de almacenamiento (HPOS) donde el esquema soporte indexación sensata.

Patrón 3: SQL_CALC_FOUND_ROWS / consultas de count para paginación

Las tablas de lista tienden a calcular el total de resultados. En datasets grandes, contar puede costar más que obtener las 25 filas que realmente muestras.

Pista de diagnóstico: Consulta similar aparece dos veces: una para IDs y otra para FOUND_ROWS o COUNT.

Dirección de corrección: Reduce filtros costosos; en algunos entornos, ajusta la UX del admin (no calcular totales exactos para cada filtro).

Patrón 4: N+1 de fetches de meta por cada fila de pedido

La pantalla de Pedidos muestra columnas: nombre de facturación, total, estado, método de pago, método de envío, notas y columnas personalizadas agregadas por plugins.
Cada columna puede disparar lookups adicionales si los datos no se precargan.

Pista de diagnóstico: Muchas SELECT ... FROM wp_postmeta WHERE post_id IN (...) similares o incluso consultas por pedido.

Dirección de corrección: Reduce columnas personalizadas, asegura que el data store de WooCommerce cachee eficazmente, usa caché de objetos, o actualiza a una versión que haga prefetch más eficientemente.

Patrón 5: Joins y subconsultas añadidas por plugins

CRMs, exportadores, herramientas antifraude y plugins de “gestión de pedidos” gustan de engancharse en las consultas de la lista del admin y añadir WHERE extras.
Cada uno parece pequeño. Juntos crean un plan de consulta que parece un tazón de espaguetis volcado.

Pista de diagnóstico: La consulta lenta incluye claves meta inesperadas, joins de taxonomías o tablas personalizadas.

Dirección de corrección: Desactiva y mide. Si el negocio requiere el plugin, pide al proveedor orientación para afinar consultas o aísla funciones a pantallas específicas.

Broma #2: SQL es como un gato—si lo ignoras, aún se sentará en tu teclado y empeorará todo.

Aceleraciones que funcionan (y qué rompen)

Seamos claros: la mayoría de las “guías de rendimiento” recomiendan caché y oración. Nosotros hacemos menos filas examinadas, mejores índices,
y menos funciones inútiles. Aquí están las correcciones que realmente mueven la aguja.

1) Habilitar HPOS (High-Performance Order Storage) cuando sea factible

HPOS mueve datos de pedidos fuera de posts/postmeta hacia tablas dedicadas diseñadas para pedidos. La ganancia no es sutil:
menos joins, mejor indexación y formas de consulta más predecibles.

Qué rompe: Algunos plugins aún asumen que los pedidos viven en posts/postmeta. Debes probar compatibilidad,
especialmente con fulfillment, subscriptions y herramientas de reporting. La migración en sí necesita planificación.

Consejo opinado: Si tienes conteos de pedidos de seis cifras y aún estás en almacenamiento legacy, HPOS suele valer el esfuerzo.
Cuanto más esperes, peor será la ventana de migración.

2) Reducir el alcance de búsqueda del admin (deja de permitir búsquedas “contiene en cualquier parte”)

El peor patrón de consulta es términos de búsqueda introducidos por usuarios mapeados a meta_value con wildcard LIKE.
“Buscar por email que contiene ‘gmail’” suena útil. A escala es una característica de denegación de servicio.

Opciones de corrección:

• Requerir coincidencia exacta de email para búsquedas de billing email.
• Usar búsqueda por prefijo (LIKE 'abc%') en lugar de contains (LIKE '%abc%') cuando sea posible.
• Añadir una UI de búsqueda dedicada que consulte una tabla indexada separada (o use búsqueda externa) en vez de escanear meta_value.

3) Añadir índices compuestos dirigidos (con cuidado)

Indexar tablas de meta de WordPress es delicado: puedes mejorar lecturas pero ralentizar escrituras y aumentar almacenamiento.
Dicho esto, algunos índices se pagan por sí mismos inmediatamente.

Formas de índice comúnmente útiles:

• (post_id, meta_key) para obtener claves específicas por pedido de forma eficiente (si tu carga lo hace mucho).
• (meta_key, post_id) para consultas que filtran por meta_key y luego se unen a posts por post_id.

Qué evitar: Indexar aleatoriamente meta_value a menos que entiendas totalmente tus patrones de consulta y la distribución de datos.
Los índices por prefijo pueden ayudar en coincidencias exactas/prefijo pero no salvan LIKE con wildcard inicial.

4) Elimina columnas y filtros administrativos costosos añadidos por plugins

Cada columna personalizada que muestra “una info más útil” puede disparar fetches de meta o joins adicionales.
Multiplícalo por 25 filas por página y por cada admin con la pantalla abierta.

Corrección: Elimina o difiere columnas. Si un plugin insiste, configúralo para que no modifique la consulta de la lista de Pedidos,
o mueve sus datos a una pantalla separada que se cargue bajo demanda.

5) Usa un caché de objetos persistente, pero trátalo como un multiplicador

Redis/Memcached puede reducir lookups repetidos entre peticiones: options, usermeta, term cache y caches de objetos de WooCommerce.
Ayuda en admin porque los administradores repiten acciones. Pero no arregla una petición única que realiza un escaneo enorme.

Corrección: Asegura que el caché de objetos sea persistente y esté dimensionado apropiadamente. También asegúrate de que no se vacíe constantemente por scripts de despliegue o plugins que rompen caché.

6) Domar los trabajos en background (Action Scheduler, importaciones, webhooks)

WooCommerce usa Action Scheduler para tareas background. Si tienes backlog, puede aporrear la BD y dejar sin recursos a las consultas admin.
Las importaciones y plugins de sync pueden hacer lo mismo.

Corrección: Limita la tasa, procesa en lotes, agenda fuera de pico. No ejecutes actualizaciones masivas al mediodía y luego te sorprendas de que la pantalla Pedidos esté lenta.

7) Dimensiona MySQL en memoria correctamente y reduce el dolor del disco

Si tu buffer pool es pequeño, cada consulta del admin se convierte en una cacería en disco. Aumenta buffer pool si RAM lo permite,
vigila swap y evita co-ubicar la BD con workloads ruidosos.

Corrección: Incrementa innodb_buffer_pool_size gradualmente, reinicia en una ventana de mantenimiento si es necesario, y mide de nuevo.
Si la latencia de almacenamiento es alta, arréglalo también—las bases de datos no tienen paciencia.

8) Actualiza WooCommerce y WordPress de forma estratégica

Mejoras de rendimiento suelen llegar en releases menores aburridos: menos consultas, mejor caching, mejor comportamiento de tablas de lista.
Quedarse muy atrás significa que sufres bugs que ya fueron resueltos—solo que no en tus servidores.

Tres microhistorias corporativas desde el campo

Microhistoria 1: El incidente causado por una suposición errónea

Un minorista de tamaño medio usó WooCommerce durante años sin problemas. Los pedidos crecían estacionalmente, pero el sitio se mantenía.
Entonces el equipo de soporte empezó a quejarse: al hacer clic en “Pedidos” daba timeout. El equipo de ingeniería miró la CPU y vio que no estaba pegada.
Lo declararon “red” y siguieron con otra cosa.

La suposición errónea: si la CPU está bien, la base de datos debe estar bien también. Mientras tanto la BD estaba examinando 20+ millones de filas en una consulta de búsqueda
generada por un macro de soporte: “buscar pedidos por email de cliente que contiene ‘@gmail.com’.” Funcionaba cuando había 30k pedidos.
Con 300k pedidos, se volvió una máquina de escaneo de tablas.

Lo “arreglaron” aumentando timeouts del proxy. La página de Pedidos dejó de hacer timeout… y empezó a tardar 40 segundos.
Soporte dejó de usar la pantalla y empezó a pedir a ingeniería consultar manualmente.
Eso no es un workaround; es una interrupción lenta.

La solución real fue poco glamorosa: eliminar la búsqueda por contains en billing email en la UI del admin, reemplazarla por coincidencia exacta y una búsqueda de cliente separada que devolviera los emails conocidos del cliente. Soporte se quejó una semana, luego lo olvidó.
La página de Pedidos bajó a menos de dos segundos porque la BD dejó de recibir consultas imposibles.

Lección: los fallos de rendimiento suelen ser decisiones de producto. Si tu UI fomenta consultas patológicas, la base de datos terminará imponiendo física.

Microhistoria 2: La optimización que salió mal

Otra compañía tenía un ingeniero amante de los índices. La página de Pedidos era lenta, así que añadieron muchos índices en wp_postmeta,
incluyendo un índice por prefijo en meta_value para varias claves. También añadieron un par de índices compuestos “por si acaso.”
Pareció excelente en un benchmark rápido.

Dos semanas después, la creación de pedidos se ralentizó. Luego los reembolsos. Luego los jobs background comenzaron a acumularse.
Las escrituras estaban pagando el coste de mantener un bosque creciente de índices secundarios. La tienda no cayó, pero todo se volvió pegajoso,
como caminar por un pasillo alfombrado con zapatos mojados.

Peor: los nuevos índices cambiaron las elecciones del query planner. Algunas consultas se hicieron más rápidas, otras empeoraron drásticamente porque el planner empezó
a usar un índice que parecía selectivo pero no lo era. De repente una consulta previamente aceptable se volvió de larga ejecución, causando contención de locks.

El rollback fue doloroso porque eliminar índices en tablas grandes no es instantáneo. Terminaron programando ventanas de mantenimiento y haciéndolo uno a uno,
mientras simultáneamente arreglaban el problema real: un plugin que generaba consultas meta con mala selectividad y wildcards.

Lección: los índices no son gratis. Añádelos como si los pagaras de tu propio presupuesto—porque lo haces, aunque sea vía latencia.

Microhistoria 3: La práctica aburrida pero correcta que salvó el día

Una tienda con muchas suscripciones tenía lentitud consistente en el admin cada lunes por la mañana. No era catastrófico, pero hacía al equipo de operaciones miserable.
El ingeniero de guardia finalmente hizo lo aburrido: recolectó slow query logs durante exactamente 15 minutos cada lunes por un mes,
luego comparó digests y planes.

El patrón fue claro: Action Scheduler procesaba un backlog de renovaciones de suscripciones, generando ráfagas de escrituras en meta y notas de pedidos,
solapándose con personal haciendo reembolsos y acciones de soporte al cliente. La BD estaba bien fuera de pico; era contención bajo carga mixta de lectura/escritura.

La solución no fue heroica. Limitaron la velocidad del scheduler, movieron el procesamiento de renovaciones a horas tempranas y añadieron observabilidad:
si la profundidad de la cola excedía un umbral, el scheduler se ralentizaba. También crearon un pool PHP-FPM separado y más pequeño solo para admin
para que el tráfico de clientes no pudiera dejar sin recursos al personal.

El lunes por la mañana volvió a ser aburrido. El negocio celebró no notándolo, que es el mayor halago para operaciones.

Lección: la medición repetida vence al pánico puntual. La práctica aburrida es recolectar evidencia comparable a lo largo del tiempo y actuar según los patrones.

Errores comunes: síntoma → causa raíz → solución

Esto es lo que desperdicia semanas. Reconoce el síntoma, mapea a una causa probable y aplica la corrección específica.

1) Síntoma: la página Pedidos es lenta solo al usar la búsqueda del admin

Causa raíz: Búsqueda en meta usando LIKE '%term%' sobre wp_postmeta.meta_value.

Solución: Restringe la búsqueda a coincidencia exacta o prefijo; añade una búsqueda de cliente dedicada; considera HPOS. Evita búsquedas “contains” en meta longtext.

2) Síntoma: la página Pedidos hace timeout durante importaciones/sincronizaciones

Causa raíz: Actualizaciones masivas reteniendo locks y saturando I/O; transacciones largas; jobs background sin rate limiting.

Solución: Procesa en lotes, reduce tamaño de transacciones, agenda fuera de pico, limita runners de Action Scheduler y monitoriza lock waits.

3) Síntoma: la página Pedidos es lenta solo para administradores

Causa raíz: Plugin añade columnas/acciones para admins, creando consultas o joins extra.

Solución: Desactiva la característica del plugin para la tabla de lista, elimina columnas o mueve los datos a una vista bajo demanda.

4) Síntoma: CPU baja, pero latencia alta

Causa raíz: Lecturas de BD dependientes de disco por buffer pool pequeño o planes de consulta pobres.

Solución: Arregla planes de consulta primero; luego aumenta buffer pool; valida latencia de almacenamiento; asegúrate de que la BD no comparta disco con jobs ruidosos.

5) Síntoma: staging es rápido, producción es lento

Causa raíz: Dataset de staging pequeño; producción tiene tablas meta enormes y cardinalidad distinta.

Solución: Prueba con datos similares a producción; usa EXPLAIN ANALYZE en formas de consulta reales; evita decisiones de rendimiento sobre datos de juguete.

6) Síntoma: “Añadimos Redis y no cambió nada”

Causa raíz: La parte lenta es una gran consulta, no lookups repetidos cacheables; o la caché se vacía/está deshabilitada para admin.

Solución: Valida slow query logs; asegúrate de que el caché de objetos persistente esté habilitado; detén el gran escaneo; no esperes que la caché arregle filtros sin índices.

7) Síntoma: después de añadir índices, las escrituras se pusieron lentas

Causa raíz: Demasiados índices secundarios en tablas calientes; el coste de mantenimiento de índices domina.

Solución: Elimina índices de bajo valor; conserva solo los que coinciden con top digests; considera cambio de esquema (HPOS) en vez de indexar tu salida del EAV.

8) Síntoma: 504s aleatorios mientras algunas solicitudes están bien

Causa raíz: PHP-FPM max children alcanzado; encolamiento bajo carga; llamadas lentas a BD reteniendo workers.

Solución: Identifica llamadas bloqueadoras vía slowlog/APM; arregla la BD; opcionalmente separa pool para admin; ajusta timeouts al final.

Listas de verificación / plan paso a paso

Checklist A: Triage de emergencia (mismo día)

1. Confirma latencia del endpoint vía access logs y curl TTFB desde servidor.
2. Revisa saturación de PHP-FPM (status): ¿estás en max children?
3. Activa PHP-FPM slowlog a 5s por una ventana corta; reproduce una vez.
4. Activa MySQL slow query log a 1s por 10–15 minutos; reproduce una vez.
5. Ejecuta pt-query-digest; elige la consulta top por tiempo total y filas examinadas.
6. Ejecuta EXPLAIN / EXPLAIN ANALYZE en la consulta exacta; haz screenshot/guarda la salida.
7. Si ves meta_value wildcard LIKE: restringe inmediatamente esa búsqueda (política/UX), o desactiva ese filtro temporalmente.
8. Si ves lock waits: identifica el bloqueador en PROCESSLIST y para/reagenda el job que lo causa.

Checklist B: Correcciones estructurales (1–2 semanas)

1. Decide sobre adopción de HPOS. Si sí, haz pruebas de compatibilidad y un plan de migración con rollback.
2. Audita plugins que enganchan la lista de Pedidos: elimina columnas y filtros no esenciales.
3. Añade solo los índices justificados por los top digests (y valida impacto en escrituras).
4. Dimensiona correctamente innodb_buffer_pool; valida que no haya swap.
5. Limita Action Scheduler y otros jobs background; establece alertas de profundidad de cola.
6. Asegura estabilidad del caché de objetos persistente (no flushs frecuentes) y monitoriza hit/miss.

Checklist C: Mantenerlo rápido (continuo)

1. Recolecta digests de slow query semanalmente (ventana corta), compara tendencias.
2. Prueba rendimiento con datos similares a producción para cualquier plugin o upgrade de WooCommerce.
3. Define un SLO de admin (p. ej., p95 de lista Pedidos < 2s) y alerta si se viola.
4. Documenta cualquier índice añadido y los patrones de consulta que sirven.

Preguntas frecuentes

1) ¿Por qué el admin de WooCommerce es lento mientras la tienda pública está bien?

Las páginas públicas son cacheables y a menudo usan page cache/CDN. Las páginas de admin son personalizadas, no cacheables,
y ejecutan consultas más pesadas (filtrado, ordenado, conteos, lookups en meta, comprobaciones de capacidades).

2) ¿El principal culpable suele ser wp_postmeta?

Frecuentemente, sí—especialmente para búsqueda y filtrado de pedidos. La combinación de muchas filas, esquema flexible
y patrones no indexados hace de wp_postmeta un repetido infractor a escala.

3) ¿Debo simplemente habilitar Redis como caché de objetos?

Habilítalo si puedes hacerlo correctamente (persistente, monitorizado, dimensionado). Pero no arreglará una única consulta lenta
que escanea millones de filas en meta. Trata la caché de objetos como un multiplicador para patrones de consulta ya razonables.

4) ¿Puedo arreglar la lentitud del admin aumentando workers PHP-FPM?

A veces reduce el encolamiento, pero también puede empeorar el problema de base de datos al lanzar más consultas concurrentes lentas.
Arregla las llamadas DB bloqueantes primero, luego ajusta la concurrencia.

5) ¿Cuál es la forma más rápida de identificar la consulta pesada?

Activa MySQL slow query log con umbral de 1s por 10–15 minutos durante una ventana de reproducción, luego ejecuta pt-query-digest.
Sigue con EXPLAIN/EXPLAIN ANALYZE en el digest top.

6) ¿Valen la pena índices en meta_value?

Rara vez para búsquedas “contains”, porque los wildcards iniciales no usan el índice. Los índices por prefijo pueden ayudar en coincidencias exactas/prefijo,
pero añaden coste en escrituras. Solo añádelos cuando un patrón top lo exija y hayas probado el impacto en escrituras.

7) ¿Cómo ayuda HPOS, en la práctica?

HPOS pone campos de pedidos frecuentemente filtrados/ordenados en columnas dedicadas con índices apropiados, reduciendo joins de meta y mejorando
las decisiones del planner. Convierte “escanear meta y esperar” en “usar un índice y recuperar filas”.

8) ¿Por qué veo “Using temporary; Using filesort” en EXPLAIN?

Significa que MySQL está creando un conjunto temporal y ordenándolo en vez de usar el orden de un índice.
Es común cuando ORDER BY no coincide con un índice, o cuando joins/filtros impiden recuperación ordenada por índice.
La corrección es mejor selectividad, índices compuestos mejores o cambiar la forma de la consulta/almacenamiento.

9) ¿Debería separar el servidor de base de datos del servidor web?

Si estás a escala significativa, sí: reduce efectos de vecinos ruidosos y facilita ajustar I/O y memoria.
Pero no uses arquitectura como sustituto de arreglar consultas patológicas. Solo tendrás una factura más grande y el mismo escaneo.

10) ¿Y si la consulta lenta viene de un plugin que no puedo eliminar?

Primero, desactiva la integración del plugin en la lista de Pedidos si es posible (columnas, filtros, llamadas en vivo). Segundo, captura las consultas exactas
y envíalas al proveedor con salida de EXPLAIN. Tercero, aísla la función a una página separada o a un job en background.

Conclusión: próximos pasos que puedes entregar esta semana

Si la pantalla de Pedidos de WooCommerce está lenta, deja de tratarla como un misterio sin resolver.
Captura la consulta lenta, lee el plan y haz que la consulta deje de escanear el universo.

1. Recolecta evidencia: slow query log (umbral 1s) + pt-query-digest + EXPLAIN para la consulta top.
2. Elimina los peores patrones impulsados por la UX: búsquedas wildcard en meta, columnas excesivas, filtros costosos.
3. Arregla la contención: limita importaciones y Action Scheduler para que el trabajo admin no compita con escrituras masivas.
4. Toma una decisión estructural: adopción de HPOS si eres pesado en pedidos y aún usas almacenamiento legacy.
5. Luego afina: dimensionamiento de buffer pool, estabilidad del caché de objetos y concurrencia de PHP-FPM—después de que la SQL esté sensata.

El rendimiento del admin es rendimiento operativo. Si tu personal no puede enviar pedidos, reembolsar o responder clientes rápidamente,
el negocio está caído aunque la página principal cargue.