Una pantalla de Pedidos lenta suele ser antes un problema de consulta que un problema de “base de datos grande”. Mide la petición exacta del administrador. Una tienda con muchos pedidos puede ir bien si índices, metadatos y tablas auxiliares están sanos; una más pequeña puede bloquearse porque una extensión añade joins o búsquedas de metadatos muy costosas.
Mide la petición que falla
Registra tiempo, número de consultas, SQL más lento y si el problema aparece al listar, buscar, filtrar o abrir un pedido. En staging, compara también con extensiones que añaden columnas o filtros al listado.
Mira qué está creciendo
Revisa tablas de pedidos, postmeta cuando aún interviene el almacenamiento legacy, Action Scheduler, sesiones y logs. El tamaño no basta: importa cuántas filas se examinan y qué consultas se repiten.
Separa HPOS de las suposiciones antiguas
Si HPOS está activo, comprueba que el código personalizado usa APIs CRUD de WooCommerce o consultas compatibles. Código que sigue suponiendo posts/postmeta puede generar lentitud o vistas incoherentes.
Corrige la consulta, no el síntoma
Archiva solo con una política de retención, añade índices después de medir el plan y elimina datos abandonados mediante el componente propietario. Subir memory_limit no arregla un patrón SQL deficiente.
Verifica con tareas reales
Prueba listado, búsqueda por cliente o pedido, filtros por fecha/estado y apertura de pedidos recientes y antiguos. Vuelve a medir después.
Si el crecimiento viene de sesiones, revisa las sesiones de WooCommerce que ralentizan la base de datos. Para reparar registros sin alterar cobros, consulta la guía de datos de pedido.