Home / Optimización de base de datos WooCommerce
WooCommerce · MySQL · catálogos grandes

Optimización de base de datos WooCommerce para tiendas que ya han crecido.

Una base de datos WooCommerce suele empezar pequeña y predecible y después acumular pedidos, sesiones, jobs de Action Scheduler, tablas de plugins, metadatos de producto y opciones autoloaded. Perfilo las consultas que realmente son lentas, corrijo patrones de datos, índices y aplicación y limpio únicamente lo que sea seguro.

Guía técnica + servicio de implementación · Revisado el 16 de agosto de 2026
01 · Lo que suele fallar

El problema suele ser el coste de las consultas, no tener demasiadas filas.

Tiendas grandes pueden funcionar rápido con millones de filas si las consultas habituales están bien diseñadas e indexadas. Tiendas pequeñas pueden ir mal si un plugin escanea metadatos repetidamente, carga opciones enormes por autoload o programa tareas en segundo plano descontroladas.

01

Consultas costosas de productos y metadatos

Filtros, búsqueda, precios personalizados e informes pueden crear consultas con muchos JOIN cuyo coste aumenta rápidamente con el tamaño del catálogo y los metadatos.

02

Almacenamiento de pedidos

HPOS y el almacenamiento de pedidos heredado usan tablas y patrones de consulta distintos. El código personalizado debe usar las APIs/patrones de consulta adecuados en lugar de asumir posts/postmeta.

03

Opciones autoload infladas

Opciones serializadas grandes cargadas en cada petición desperdician memoria y pueden aumentar el trabajo de PHP/MySQL incluso en páginas que no necesitan ese estado del plugin.

04

Cola atrasada de Action Scheduler

Importaciones, webhooks, email, suscripciones e integraciones pueden crear colas grandes que consumen capacidad de base de datos y workers.

05

Sesiones y transients

Sesiones/transients caducados y datos de caché de extensiones pueden acumularse. La limpieza es útil cuando la evidencia muestra que afecta la eficiencia de consultas o tablas.

06

Índices faltantes o ineficaces

Tablas personalizadas y consultas de plugins pueden filtrar u ordenar por columnas sin índices útiles. Añadir un índice puede ayudar muchísimo, pero solo después de confirmar la consulta lenta exacta y el coste en escrituras.

02 · Diagnosticar antes de cambiar

Empieza con evidencia de consultas lentas, no con folklore sobre wp_options.

Perfilo peticiones reales — edición de producto en admin, filtros frontend, checkout, importaciones, informes — y rastreo el SQL dominante. Eso indica si la solución debe estar en limpieza, un índice, una consulta de plugin, el diseño de caché o el código de aplicación.

Query Monitor / APM

Vincula el SQL costoso a una página/petición y a un plugin/callback en lugar de optimizar tablas sin impacto visible para el usuario.

EXPLAIN / uso de índices

Inspecciona el número de filas escaneadas, el orden de los JOIN y si los índices existentes soportan el patrón WHERE y ORDER BY de la consulta real.

Peso del autoload

Mide el tamaño y propietario de las options autoloaded; mueve o elimina solo datos comprendidos y que ya no son necesarios.

Salud del scheduler

Revisa acciones pendientes/fallidas, tareas recurrentes y throughput para que el trabajo en segundo plano no monopolice recursos silenciosamente.

Compatibilidad con HPOS

Verifica que las integraciones a medida utilicen las APIs de pedidos de WooCommerce o patrones compatibles con HPOS, en lugar de depender directamente del postmeta legacy.

Perfil de crecimiento

Identifica qué tablas/conjuntos de datos crecen más rápido y relaciona ese crecimiento con funciones de negocio, importaciones, sesiones o logging antes de definir retención.

03 · Implementation

Haz predecible el trabajo de base de datos en las peticiones que generan ingresos.

Limpiar es la respuesta equivocada cuando el problema real es una mala consulta. Prefiero cambios que sigan siendo rápidos a medida que crecen pedidos y productos.

Detectar cargas lentas

Perfila checkout, filtros/búsqueda del catálogo, admin e importaciones/tareas en segundo plano usando datos similares a producción.

Corregir consultas de la aplicación

Elimina búsquedas N+1 repetidas, meta queries amplias, SQL directo sobre pedidos heredados y conteos innecesarios antes de ajustar MySQL alrededor de ellos.

Añadir índices específicos

Crea o ajusta índices solo para patrones de consulta de alto valor demostrados y comprueba el coste de escritura/almacenamiento.

Reducir datos cargados

Reduce o desactiva el autoload de options de plugins sobredimensionadas y limpia sesiones, transients y logs obsoletos de forma segura tras verificar su origen.

Controlar colas en segundo plano

Corrige schedules descontrolados, importaciones y tareas de webhooks/suscripciones para que no compitan agresivamente con el tráfico de checkout/frontend.

Documentar el mantenimiento

Define reglas de retención, limpieza y re-perfilado para la tienda concreta en lugar de ejecutar a ciegas un limpiador genérico.

04 · Lo que realmente recibes

Un plan de base de datos basado en consultas, no en supersticiones.

Obtienes evidencia de antes/después para las peticiones lentas y un modelo de mantenimiento adaptado a la carga de pedidos, catálogo e integraciones de la tienda.

01

Hallazgos de consultas lentas

SQL de alto coste mapeado a la página, plugin o tarea que lo dispara.

02

Correcciones de consultas y código

Cambios compatibles con WooCommerce/APIs que eliminan accesos a datos repetidos o mal planteados.

03

Índices específicos

Índices o cambios de tablas justificados por evidencia de EXPLAIN/consultas, con notas de rollback.

04

Limpieza segura

Solo se eliminan datos conocidos como obsoletos o caducados, con backup y comprobaciones en staging.

05

Ajuste de scheduler y sesiones

Datos de background y sesiones gestionados para que las peticiones comerciales de primer plano sigan siendo predecibles.

06

Controles para crecer

Recomendaciones de retención y monitorización para pedidos, logs, feeds, webhooks y tablas de extensiones.

Si checkout o wp-admin se vuelven más lentos cada mes, perfila la base de datos antes de comprar un servidor más grande.

Para base de datos junto con rendimiento frontend, carrito y checkout, el servicio amplio de rendimiento WooCommerce es la opción adecuada.

FAQ

Preguntas que recibo antes de tocar producción.

¿Cómo sé si la base de datos de WooCommerce es lenta?

Perfila solicitudes reales e inspecciona tiempo de base de datos y número de consultas. Una tabla grande de opciones o pedidos no es una prueba por sí sola; la evidencia son SQL costosos, muchos registros escaneados, contención o acceso repetido a datos en flujos importantes.

¿Debería borrar transients y sesiones de WooCommerce?

Los datos caducados u obsoletos pueden limpiarse, pero borrar no sustituye corregir problemas de consultas o aplicación. Entiende a qué pertenece cada dato, haz backup primero y evita eliminar estado activo de clientes o sesiones.

¿HPOS hace WooCommerce más rápido?

HPOS proporciona tablas dedicadas para pedidos y un modelo de datos orientado a comercio. El rendimiento sigue dependiendo de extensiones, consultas, índices y carga de trabajo, así que el código a medida debe ser compatible con HPOS.

¿El autoload de wp_options puede ralentizar WooCommerce?

Sí, si grandes cantidades de estado de plugins se cargan en cada petición. Mide el payload total de autoload e identifica su origen antes de cambiar flags de autoload o borrar opciones.

¿Puedo simplemente instalar un plugin de limpieza de base de datos?

Las herramientas de limpieza pueden eliminar revisiones/transients y optimizar tablas, pero no pueden corregir una mala consulta a medida, un índice ausente o una cola de jobs fuera de control. Úsalas como herramientas de mantenimiento, no de diagnóstico.

¿Es seguro añadir índices a la base de datos?

Los índices mejoran las lecturas, pero añaden coste de almacenamiento y escritura. Deben basarse en una consulta realmente lenta y probarse con datos similares a producción y un plan de rollback, especialmente en tablas grandes.