Autoload, revisions, and a query that holds every PHP worker.
We do not install a cleaner plugin and call the database optimized. A dump first. Then the table that is actually large, or the option that loads on every request.
Options, revisions, sessions, a log plugin
wp_options with autoload yes, grown by a plugin that stored a megabyte in a row. That loads on every hit. We name the option before deleting anything.
Expired transients and unbounded revisions. Safe to prune after a dump. Posts and orders are not in that set.
The slow log names it. An index is added only if the table is a known WordPress table. A custom plugin table is reported, not rewritten.
Orders, users, and the posts table are not clutter
A WooCommerce database is large because it has orders. Shrinking it by deleting those rows is not optimization. If the server is the limit, the answer is a bigger box or a slower job moved off the request. MariaDB itself, if it will not start, is the other page.
€55 an hour, dump included in the first hour if it fits
Minimum 1 hour. A database of tens of gigabytes is quoted before anyone runs a prune. No table is dropped without a dump you can still reach.
wp-admin slow, or the database larger than the site?
Tell us the host and whether it is WooCommerce. No database password in the first message.