Checkout puede expirar mientras PHP espera que MySQL lea, bloquee o escriba datos. La consulta costosa puede pertenecer a WooCommerce, una extensión o código ejecutado al crear la orden. Aumentar el timeout solo prolonga la espera si el trabajo no mejora.
Concilia los pagos antes de repetir. Un timeout del navegador no demuestra que transacción o escritura fallaran.
Captura la petición bloqueada
Registra hora, duración, endpoint, ID de pedido si existe y referencia de pasarela. Relaciónalo con logs PHP, servidor y MySQL.
- huella de consulta, no valores
- duración y filas examinadas
- espera por lock
- host/hilo de base
- plugin o stack llamante
Oculta direcciones, emails, sesiones y literales SQL.
Activa slow log con cuidado
Usa la herramienta del hosting durante un periodo acotado. Elige un umbral que capture el retraso sin generar un volumen inmanejable.
No actives general log a la ligera: expone valores y consume disco. Protege los registros, limita retención y desactiva el diagnóstico temporal.
Separa ejecución y espera
Una consulta bien indexada puede esperar tras una transacción larga. Inspecciona procesos, waits InnoDB y deadlocks durante una reproducción.
Importaciones, backups o analítica pueden retener locks. Muévelos fuera de horas punta y divide el trabajo. No mates hilos sin identificar propietario e impacto de rollback.
Anota tabla, índice, tipo de lock, transacción bloqueadora y bloqueada. El archivo citado por el fatal no identifica necesariamente al dueño del bloqueo. Si procede de un importador, reduce el lote y confirma que hace commit; si nace en checkout, busca una llamada externa ejecutada antes de cerrar la escritura.
Analiza el plan
Ejecuta EXPLAIN sobre una consulta equivalente anonimizada en staging:
EXPLAIN
SELECT order_id
FROM wp_wc_orders
WHERE status = 'wc-processing'
ORDER BY date_created_gmt DESC
LIMIT 20;
Revisa acceso, índice, filas estimadas y ordenación temporal. Prefijo y esquema pueden variar. No añadas un índice por este ejemplo; usa la consulta real y la versión instalada.
Compara el plan con un volumen parecido a producción. Una tabla pequeña de staging puede elegir otra estrategia. Actualiza estadísticas mediante procedimientos soportados y demuestra que el índice reduce filas examinadas sin perjudicar las escrituras frecuentes.
Comprueba HPOS
HPOS reduce dependencia de posts, pero extensiones antiguas pueden escanear wp_postmeta o forzar sincronización.
Revisa estado del sistema y compatibilidad. En código propio usa wc_get_orders() y CRUD. Repara acciones HPOS fallidas antes de cambiar almacenamiento, con copia y ensayo en staging.
Localiza consultas sin límites
Busca WP_Query, get_posts() y wc_get_orders() sin límites prácticos en el stack. Un hook de checkout no debe cargar todo el historial o catálogo.
Consulta solo IDs/campos necesarios, filtra de forma estable y cachea únicamente referencia no personal. No caches carrito o respuesta de pedido públicamente.
Mueve llamadas externas no críticas después de guardar la orden. Si una transacción queda abierta durante la API, retendrá locks innecesarios.
Separa el camino obligatorio —pedido, líneas, stock y referencia de pago— de email, CRM y analítica. Lo segundo puede ejecutarse en una tarea idempotente cuando la orden ya sea durable, dejando un estado recuperable si falla.
En bases replicadas, asegura que escrituras y lecturas inmediatas respeten consistencia. Una réplica retrasada puede hacer parecer ausente el pedido y provocar trabajo repetido.
Aplica una reparación acotada
Corrige consulta, índice, lote, lock o hook demostrado. Haz backup antes de cambiar esquema y usa mantenimiento online del hosting cuando exista.
Define condiciones de reversión: tiempo de checkout, locks, carga MySQL y espacio libre. Un índice grande puede necesitar almacenamiento adicional para construirse y replicarse; no inicies el cambio sin margen y una ventana observada.
Evita plugins limpiadores genéricos que borren tablas o metadatos sin conocer dependencias.
Verifica pedido y base
Ejecuta checkouts controlados con carritos representativos mientras monitorizas duración, locks y respuesta PHP. Confirma un pedido, un pago, stock y email.
El mantenimiento recurrente debe seguir huellas lentas, crecimiento y acción programada más antigua. Una ficha de producto rápida no demuestra que la ruta de escritura transaccional esté sana.