This thread is resolved. Here is a description of the problem and solution.
Problem: The client is trying to optimize their database, which has grown significantly due to numerous entries in the posts_meta table. They reported that WPML Delete Jobs did not effectively reduce the database size. Solution: We analyzed the database and found that the _postsmeta table was indeed the largest. We also discovered a large number of attachment entries that might be bloating the database. We recommend creating a staging version of the website and running the following SQL queries to clean up unnecessary entries:
SELECT p.ID FROM `93lzr5_posts` p LEFT JOIN `93lzr5_icl_translations` t ON p.ID = t.element_id WHERE p.post_type = 'attachment' AND t.element_id IS NULL;
DELETE pm FROM `93lzr5_postmeta` pm WHERE pm.post_id IN (SELECT p.ID FROM `93lzr5_posts` p LEFT JOIN `93lzr5_icl_translations` t ON p.ID = t.element_id WHERE p.post_type = 'attachment' AND t.element_id IS NULL);
DELETE p FROM `93lzr5_posts` p LEFT JOIN `93lzr5_icl_translations` t ON p.ID = t.element_id WHERE p.post_type = 'attachment' AND t.element_id IS NULL;
Please ensure to perform these actions on a staging site and not on the live site. If this solution does not apply or is outdated, we recommend checking related known issues, verifying the version of the permanent fix, and confirming that you have installed the latest versions of themes and plugins. If further assistance is needed, please open a new support ticket.
This is the technical support forum for WPML - the multilingual WordPress plugin.
Everyone can read, but only WPML clients can post here. WPML team is replying on the forum 6 days per week, 22 hours per day.
Background of the issue:
I am trying to optimize my database for the site hidden link. I have contacted my hosting service, and they explained that WPML has created thousands of rows in my tables, bloating my database from 2GB to over 4GB, most of this in posts_meta (3.7GB).
Symptoms:
WPML Delete Jobs did basically nothing to reduce the database size.
Questions:
How can I effectively reduce the size of my database?
Is there a more effective way to clean up the posts_meta table?
Are there any other WPML tools or methods to optimize the database?
Thank you for sharing the results. So, in this case, we can work it around. Please download your DB file from your hosting, upload it to Google Drive, Dropbox, or another cloud service from your choice. Please share the link, so I can download it. If possible, please also download and share the website files, so I can create a manual copy, locally.
With that information, I can analyze the DB. Let me know how it goes.
I think the only way I can share anything this big is by using OneDrive, but to be able to share the link there I need private message option since it is not something I can share in public forum and if I have understood right I need an invite to the private message to be able to give one?
Google Drive, WeTransfer can handle the file just fine, as well. Just pointing that out.
I've activated a private field, you will likely find it under the message box. It's a field to share the Duplicator package, but you can use it to insert any link you want. Let me know if it shows up. This field will only allow you and me the see the link.
Apparently. I couldn't import the files you shared, due to errors. Nonetheless, I've forwarded the information we currently have to our devs, to get a second opinion. I'll get back once I hear from them. Thank you for your patience and cooperation.
We thoroughly analyzed your DB, and couldn't confirm that the issue was indeed being caused by WPML.
1. First, we checked the size of the _postsmeta table, and it was indeed the largest one. Check image wpml_001;
2. We also checked, and in _posts, you have more than 1 million entries there, which is a lot higher than your actual number of media entries. Check image wpml_002;
3. There are 24,924 rows with attachment "new survey" created "2024-11-28 13:56:22" exactly... This indicates some issue, and it is not new according to the date;
4. By sorting the _postmeta table by metakey, we noticed that the entries created by wpml, are similar to the number of entries created by the attachments, which is expected behavior. Check image wpml_003;
This information is not conclusive, but there's a strong indication that there's something bloating the DB. Since WPML has to create entries in other languages for your website's content, it's following that pattern.
To move forward with that, since I could not import the DB files you sent (which are apparently corrupt), what I can recommend is for you to create a copy or staging version of your website. Then, remove the attachment meta and attachment post-entries that do not have an entry in the icl_translations table. I couldn't test the queries, since I don't have a copy, but you can try using the ones below:
To list all attachments without an entry:
SELECT p.ID
FROM `93lzr5_posts` p
LEFT JOIN `93lzr5_icl_translations` t ON p.ID = t.element_id
WHERE p.post_type = 'attachment'
AND t.element_id IS NULL;
Then you can run this query to remove the postmeta:
DELETE pm
FROM `93lzr5_postmeta` pm
WHERE pm.post_id IN (
SELECT p.ID
FROM `93lzr5_posts` p
LEFT JOIN `93lzr5_icl_translations` t ON p.ID = t.element_id
WHERE p.post_type = 'attachment'
AND t.element_id IS NULL
);
And finally, to remove the posts
DELETE p
FROM `93lzr5_posts` p
LEFT JOIN `93lzr5_icl_translations` t ON p.ID = t.element_id
WHERE p.post_type = 'attachment'
AND t.element_id IS NULL;
As I said, this has not been tested and must not be done in the official website. Perhaps cleaning this suspect entries will also reduce the size of WPML entries, as they correspond to the existing ones, as expected.
It seems that this resolved the issue. So the reason it seemed like WPML was the culprit was that the image optimization plugin we used at the start of the website when we bulk loaded images was creating "invisible" copies to the database. And then later when we installed WPML, it made copies for each language using this media. The only thing that is mystery is why this was delayed process and not made right away, but nevertheless the main issue is now solved and database is once again manageable size.
And lesson learned is that using image optimization plugin that might bloat your database is very bad idea when combined to WPML since it multiplies the bloat simply working like is supposed to work.