A growing WooCommerce sessions table does not by itself prove why the store is slow. Compare creation and expiration, check whether cleanup runs, and identify the queries delaying cart or checkout. Active cart state needs to survive the repair.
Do not empty the session table to make a size graph fall. If carts or checkout are affected, review the WooCommerce repair assessment and send the measured symptoms before changing data.
Measure size and growth
Take a database backup and inspect row count, data size and oldest/newest expiry values. Use the actual WordPress table prefix.
SELECT COUNT(*) AS session_rows,
MIN(session_expiry) AS oldest_expiry,
MAX(session_expiry) AS newest_expiry
FROM wp_woocommerce_sessions;This SQL example applies to the standard database session table. Confirm the installed session handler and table prefix first; a custom handler may store data elsewhere. On a busy store, agree how to collect counts without adding avoidable load. Record totals, not customer session values.
Run read-only queries through an authorised database account. Do not paste session values into reports; serialized cart data can contain customer information.
Repeat the count after a known interval to calculate growth rather than relying on one large number.
Measure during both normal traffic and known campaign peaks because their creation rates can differ substantially.
Confirm expired-session cleanup runs
Check the WooCommerce version first. WooCommerce 10.1 migrated its cron jobs to Action Scheduler, so review Scheduled Actions and their logs on current installations. Earlier versions scheduled woocommerce_cleanup_sessions in WP-Cron. Not finding a task in the wrong scheduler proves little.
Check overdue executions, errors and the mechanism that triggers background work on that host. Record the last successful run and compare expired-row counts before and after it. Repair the scheduling fault before a manual cleanup.
Separate database size from query slowness
Use the slow-query log or hosting database metrics to identify which query is expensive. A large table with healthy indexes may not be the primary bottleneck, while disk pressure or missing indexes can make smaller tables slow.
Check table status and WooCommerce’s expected schema. Do not add speculative indexes without examining query plans and compatibility with future WooCommerce updates.
Also inspect Action Scheduler and order tables; checkout latency can be blamed on sessions when another table is responsible.
Look for bot-generated carts
Bots can hit add-to-cart URLs, variation APIs or abandoned checkout flows and create sessions at machine speed. Compare session growth with access logs using aggregated IP/rate information, user agents and requested routes.
Apply rate controls to abusive patterns without blocking genuine checkout or search-engine access. Avoid a challenge on every cart request; it can break payment callbacks and accessibility.
Remove public links that unintentionally trigger add-to-cart for crawlers where appropriate.
Review custom session retention
Custom code and plugins may extend expiration or store excessive payloads. Search maintained code for WooCommerce session expiration filters and large custom session keys.
Store only short-lived checkout state needed for the transaction. Permanent preferences belong in an appropriate customer record, not an ever-growing guest session.
Changing expiry affects active carts and marketing expectations, so agree the retention period with the store owner.
Clean expired data safely
After backup and scheduler repair, use WooCommerce’s supported cleanup mechanism or a carefully bounded deletion of rows proven expired. Test on staging and schedule production work during lower traffic.
Never delete unexpired rows merely to reduce table size. Monitor locks, replication and disk space during significant maintenance.
Optimising a table may require temporary extra disk and can lock writes depending on MySQL configuration. Use the host’s supported method and rollback plan.
Verify customer and database behaviour
Track row count, expired-row count, query latency and checkout response time after repair. Create a controlled cart before maintenance and confirm its expected survival when the session is still valid.
Complete guest checkout and verify order, payment and stock. Database improvement is incomplete if active carts break.
Recurring care should alert on cleanup failures, abnormal session-creation rate, disk growth and slow checkout queries. Healthy session management combines application scheduling, bot control and measured MySQL maintenance.
Prepare a database and checkout assessment
Send the WooCommerce version, session handler if known, table size, counts measured at two times, expired-row count and affected journey. Add whether growth follows campaigns or suspicious requests. A large table with fast queries needs a different investigation from a smaller one with expensive queries.
For targeted cleanup, read how to review broken sessions without emptying every cart. The repair process explains scope and approval. Request an assessment if database work could affect ongoing purchases.
Reference documentation
The WooCommerce 10.1 session and cron advisory explains the scheduler migration. Compare the older scheduling code and current session handler with your installed version. The WooCommerce cookie reference describes the cart-session relationship.