Home Forums ACF PRO Regarding Performance & DB Cleanup


Regarding Performance & DB Cleanup

  • Hi,

    During the site development, I had to create many post types, taxonomies and ACF fields.

    Before making live, I deleted most of the post types, taxonomies and ACF fields.

    I feel WP-ADMIN and search became slow on the site. People recommended cleaning unused database tables and meta from the database. When I checked the postmeta table, I found that all the deleted ACF fields of the posts are still there. I can see thousands of unwanted records starting with “_” (underscore).

    My questions are:

    1. Is there any way to remove those meta? (I tried few plugins like Advanced DB Cleaner Premium, but no luck)

    2. Does this orphan data make the backend and site search slow?

    If this affects the performance of the site, then I need to manually transfer the data to a fresh WP installation. It may take days to complete!

    Please recommend.


  • Hey,

    I needed to delete a big amount of unused fields for a website we’re maintaining for years. As fields get renamed or deleted, meta fields stay unused in the database. While the size of the database gets unnecessary bigger we also had an issue in the search (since old fields were found).

    I didn’t found a proper and safe solution without a heavy SQL query to remove those data. So I created a plugin using functions provided by ACF to remove unused metadata.

    Create a database dump and give it a try:

    Hope it helps and not just me
    Cheers Marc

  • Some tips.

    When working on a dev site, let’s say that you create a custom post type, add a bunch of field, populate a some content for testing. Then you decide that you want to delete this post type. You should not just delete the post type. This will not remove the posts from the database of any data associated with the posts. The first step is to delete all of the posts. Move them to trash and then delete permanently. This will cause WP to remove the posts from the DB and all associated meta data.

    The same is true of custom taxonomies. But if you crate custom taxonomies for your custom post types then the first step before deleting the posts is to delete all the terms in the custom taxonomy and then delete the posts and finally delete the post types and taxonomies.

    However, event with the old posts and fields in the DB, since these posts and fields will never be queried then they should not slow things down.

    If you just delete fields without deleting the post types and taxonomies they are attached to or if you delete fields on options pages then any data entered into the fields will linger.

    As far as slowing down the DB. This has been asked often. Having unused data in the DB will not in and of itself cause queries to be slow. Queries on meta data almost all of the time include something like “meta_key = your_field_name”. The meta_key field is and indexed row in the DB. The DB will not look even look at the fields that are left behind when performing these queries. There would need to be many, many (hundreds or thousands, or more) of unused fields in the DB to significantly effect the performance of the index. Queries that will cause and impact are those that are searching the “meta_value” without included a “meta_key” and the worst of these are “LIKE” queries on the “meta_value” without including the “meta_key”, but as long as the “meta_key” in included the extra fields are just ignored. In addition, any “LIKE” query is a query that will be suspect in site performance. When building a site this should be taken into consideration and alternatives should be explored. That said, most searching plugins that add custom fields to standard WP search ARE doing “LIKE” queries on the meta_value field without a meta_key and these search plugins will get slower.

  • What’s the state of the art on this issue of deleting unused/orphaned field data?

    I read the long thread, which is now closed –

    @marcwieland95’s whatwedo-acf-cleaner seems high-risk – blind deletion of database data
    @Bettylex’s edit-custom-fields plugin was removed from the repo on security grounds but is still on GitHub.
    – Can I learn how to delete orphaned ACF fields by searching under the general bracket of removing WordPress orphaned custom meta data, or is there something unique about ACF’s involvement?

    I am identifying fields to delete, but I’m hesitant to do so in case I have no way to remember their names. And that doesn’t even include the “how” of deleting specific fields.

  • Orphaned meta data means that a corresponding post ID for a meta entry in the db no longer exists.

    The issue is that meta data is related to the post and there is no relationship with the ACF field group, this means that if a field is deleted that the values saved in that field will not be deleted. There is no safe, scalable solution form removing this data.

    There is an action in ACF that is called after the post for the field is deleted.

    do_action( 'acf/delete_field', $field );

    Using this hook you would need to query the meta table for the field key reference of the field.

    WHERE meta_value = "{$FIELD_KEY}"

    You could use this to get a list of all of the posts that this field was related to. With this information you could then delete all of the meta values

    WHERE post_id IN {$LIST_OF_POST_IDS} AND meta_key IN ("{$field_name}", "_{$field_name}")

    Not sure if this will help you or not.

  • Thanks.

    Ahh, so an item in wp_postmetawould onjly be “orphaned” if I deleted the post those meta are linked to.

    That won’t necessarily solve a situation in which I would no longer want to have the postmeta at all – ie. If I stop using custom fields.

    Related –
    If I understand correctly, the Field Groups themselves are essentially stored as posts (in the wp_posts table).
    What happens if I delete a Field Group? Is that info adequately deleted from


  • No, the field data is not associated with the field group post, only the post that it is saved for.

Viewing 7 posts - 1 through 7 (of 7 total)

You must be logged in to reply to this topic.