WooCommerce sessions and Redis

WooCommerce sessions store cart and checkout state for each shopper. By default those rows live in MySQL, where abandoned carts and bot traffic can make the table grow quickly. Redis can hold that session data instead, so InnoDB is not stuck serving a pile of old carts. Cleaning expired sessions on a real schedule matters either way.

How MySQL sessions get out of hand

Each cart is a row in the wp_woocommerce_sessions table. Bots that hit add-to-cart, visitors who leave, and long “remember me” windows all leave data behind. WooCommerce ships a cleanup job for expired sessions, but that job only runs when wp-cron actually fires. If cron is unreliable, the table becomes part of the working set. Checkouts slow down, backups take longer, and more RAM goes to MariaDB for rows you no longer need.

Object cache does not fix this problem on its own, because session traffic is heavy on writes. Cleanup plugins that “optimize” the table without understanding it can lock it during busy hours. Prefer WooCommerce’s own expiration settings and a working system cron. After cleanup, check the table size again. If it is still huge, look for bots or a cache setup that never excludes cart and checkout.

Redis for sessions versus object cache

Object cache and session storage are not the same thing. Redis as an object cache (via object-cache.php) helps options, transients, and repeated queries. A dedicated WooCommerce session handler that talks to Redis keeps cart blobs off InnoDB. You can use both layers when the shop needs them. Dumping sessions into the general object cache can work on a quiet store, then evict a cart mid-checkout when Redis hits maxmemory. That pattern is a poor fit for a busy cart.

If you enable a session plugin, set a memory cap on Redis, match the TTL to WooCommerce’s session lifetime, and stop leaving the MySQL table to grow as a backup. Pick one place to store sessions and stick with it.

A practical order of steps

On a modest catalog, start with MySQL sessions, reliable wp-cron cleanup, and LSCache exclusions for cart and checkout. When wp_woocommerce_sessions is large or checkout is clearly InnoDB-bound, move sessions to Redis with a cap and a TTL. Take a backup, then truncate the old table once the new handler is confirmed. Do not add a third plugin that writes sessions somewhere else “just in case.”

On our shared hosting, you get cPanel with LiteSpeed and CloudLinux LVE, without root access. VPS plans include root if you need to tune Redis yourself. AutoSSL and WP Toolkit are available on WordPress accounts when you want a cleaner baseline before you change session storage.