Que crezca la tabla de sesiones de WooCommerce no demuestra por sí solo por qué la tienda va lenta. Compara creación y caducidad, comprueba la limpieza y localiza las consultas que retrasan carrito o checkout. El estado de los carritos activos debe sobrevivir a la reparación.
No vacíes la tabla para reducir una gráfica de tamaño. Si afecta a compras o carritos, consulta la evaluación de reparación de WooCommerce y envía los síntomas medidos antes de modificar datos.
Mide tamaño y crecimiento
Haz copia y consulta filas, tamaño y expiraciones usando el prefijo real.
SELECT COUNT(*) AS session_rows,
MIN(session_expiry) AS oldest_expiry,
MAX(session_expiry) AS newest_expiry
FROM wp_woocommerce_sessions;
Este ejemplo SQL corresponde a la tabla de sesiones del gestor estándar. Confirma primero el gestor instalado y el prefijo; una implementación personalizada puede guardar los datos en otro lugar. En una tienda con actividad, acuerda cómo obtener los recuentos sin añadir carga innecesaria. Registra totales, nunca valores privados de sesión.
Usa una cuenta autorizada de solo lectura. No copies valores serializados; pueden incluir datos del cliente.
Repite después de un intervalo y compara tráfico normal con campañas. Una cifra aislada no explica la tasa.
Relaciona cada medición con visitas, peticiones de carrito y sesiones caducadas. Si las filas suben durante una campaña y bajan después, la limpieza probablemente funciona; si aumentan de forma continua durante días, hay que investigar el planificador. Comprueba también el tamaño real en disco: borrar registros no siempre devuelve espacio inmediatamente y una tabla fragmentada puede requerir mantenimiento coordinado con el proveedor.
Confirma la limpieza programada
Comprueba primero la versión. WooCommerce 10.1 trasladó sus tareas cron a Action Scheduler: en instalaciones actuales, revisa Acciones programadas y sus registros. Las versiones anteriores programaban woocommerce_cleanup_sessions en WP-Cron. Buscar en el planificador equivocado no demuestra que la tarea falte.
Revisa ejecuciones atrasadas, errores y el mecanismo que activa el trabajo en segundo plano en ese alojamiento. Anota la última ejecución correcta y compara las filas caducadas antes y después. Repara el fallo de programación antes de una limpieza manual.
Separa tamaño de lentitud
Usa slow query log o métricas del hosting para identificar la consulta costosa. Una tabla grande con índices sanos puede no ser el cuello, mientras disco o índice ausente ralentizan una menor.
Compara el esquema esperado por la versión y examina planes de ejecución. No añadas índices especulativos que choquen con actualizaciones.
Revisa también Action Scheduler y pedidos: el checkout puede culpar a sesiones cuando otra tabla domina.
Busca carritos creados por bots
Los bots pueden llamar add-to-cart, variaciones o checkout abandonado a velocidad de máquina. Compara crecimiento con logs agregados por ruta, frecuencia y user agent.
Aplica límites al patrón abusivo sin bloquear compradores ni buscadores. No pongas un challenge en cada petición de carrito: rompe accesibilidad y callbacks.
Elimina enlaces públicos que disparen add-to-cart involuntariamente.
Revisa la retención personalizada
Plugins o código pueden ampliar la caducidad o almacenar payloads grandes. Busca filtros de expiración y claves de sesión propias.
Guarda solo estado efímero necesario. Las preferencias permanentes pertenecen al perfil del cliente u otro modelo.
Cambiar la duración afecta carritos y marketing; acuerda el periodo con el negocio y privacidad.
Mide tamaño medio y detecta claves anómalas sin exportar contenidos.
Limpia datos caducados con seguridad
Tras copia y reparación del scheduler, usa el mecanismo soportado o elimina únicamente filas demostrablemente expiradas mediante una operación acotada y probada en staging.
Programa en horas de menor tráfico y vigila locks, replicación y disco. No borres filas vigentes para reducir tamaño.
Optimizar tabla puede necesitar espacio temporal y bloquear escrituras según MySQL. Sigue el método del host y prepara reversión.
Divide el trabajo en lotes si el volumen lo exige.
Antes de cada lote cuenta de nuevo las filas que cumplen el criterio y establece un límite de tiempo. Así puedes detener la operación si crecen los locks o la latencia del checkout. Guarda el recuento previo y posterior, no una copia de los datos de sesión, para que la intervención sea auditable sin exponer información del cliente.
Verifica clientes y base de datos
Monitoriza filas, caducadas, latencia y respuesta del checkout. Crea antes un carrito controlado no caducado y confirma que sobrevive.
Completa checkout invitado y comprueba pedido, pago y stock. Una mejora MySQL que rompe carritos no está terminada.
Observa varios ciclos de expiración para demostrar que crecimiento y limpieza se equilibran.
El mantenimiento recurrente debe alertar por tareas fallidas, ritmo anormal, disco y consultas lentas. La salud combina cron, control de bots y mantenimiento MySQL medido.
Prepara una evaluación de base de datos y checkout
Envía la versión de WooCommerce, el gestor de sesiones si lo conoces, tamaño de tabla, recuentos en dos momentos, filas caducadas y recorrido afectado. Indica si el crecimiento coincide con campañas o peticiones sospechosas. Una tabla grande con consultas rápidas necesita una investigación distinta de una pequeña con consultas costosas.
Para una limpieza concreta, consulta cómo revisar sesiones rotas sin vaciar todos los carritos. El proceso de reparación explica alcance y aprobación. Solicita una evaluación si intervenir en la base de datos puede afectar a compras en curso.
Documentación de referencia
El aviso de sesiones y cron de WooCommerce 10.1 explica el cambio de planificador. Compara el código de programación anterior y el gestor de sesiones actual con la versión instalada. La referencia de cookies describe su relación con el carrito.