
Ask HN: Dealing with WordPress wp_options table - brianjking
The WordPress wp_options table can quickly get filled with a copious number of rows causing page load time to increase and server&#x2F;db load to increase.<p>There are several plugins for clearing the entire wp_options table and generally clear all of the posts, pages, comments, etc and return your installation to a vanilla WordPress install; however, I&#x27;m looking for a way to remove only the rows in wp_options that are not used anymore.<p>For example: removing old theme data stored in wp_options, plugin data&#x2F;configurations, etc.<p>Does anyone have any tips for even identifying which data can be removed?
======
cjmosure
I've had to do this a couple of times with some sites having 10s of thousands
of records in their wp_options. Most records are prefixed with a plug-in name,
you can just search %pluginname_% and in my experience it's only a handful of
plugins that write such a volume of records to wp_options.

~~~
gburt
This is an ok angle for dealing with well-behaved (prefixed) plugins that are
no longer in use.

Perhaps a better solution is to write a custom implementation of get_option
(and update_option, etc. if you feel necessary) which logs uses -- run this
temporarily and remove anything that hasn't been used in X days. I'd then go
through and browse all the admin. pages by hand just to ensure something rare
isn't missed.

In that case, "remove" should probably mean "copy to a different database"
just in case it turns out it had value.

~~~
gburt
Also, a thought: if you have a huge amount of records in that table, they're
probably transients or other cache material from a somewhat misbehaved plugin.

A way to "handle" that (other than the obvious and important technique of
identifying and fix whatever is creating them) is to install an in-memory
caching plugin that will store transients in RAM instead of in the database.

