A slow WooCommerce Orders screen is usually a query problem before it is a “large database” problem. Measure the exact admin request first. A store with many orders can remain responsive when indexes, metadata and background tables are healthy; a smaller store can become unusable after one extension adds an expensive join or wildcard meta query.
Measure the failing request
Record load time, SQL count, the slowest queries and whether the problem affects the list, search, filters or opening one order. Compare an administrator request with plugins that add order-list columns or filters disabled in staging.
Check what is growing
Review order tables, postmeta where legacy storage is still involved, Action Scheduler, sessions and logs. Table size alone is not enough: look for rows scanned, missing indexes and repeated meta lookups.
Separate HPOS from legacy assumptions
If HPOS is enabled, confirm custom code uses WooCommerce CRUD APIs or compatible queries. Extensions that still assume posts/postmeta can create slow fallbacks or inconsistent views.
Fix the query, not the symptom
Archive only data with a retention rule, add indexes only after measuring the query plan, and remove abandoned transient/log data through the owning component. Raising PHP memory does not repair an inefficient SQL pattern.
Verify with representative admin work
Test order list, search by customer/order number, date/status filters and opening recent/old orders. Re-measure query time after the change.
For database growth caused by sessions, see WooCommerce sessions and database slowdown. When repairing order records, preserve payment history as described in the order-data repair guide.