Table optimization still doesn’t work in 2.2.10
-
Since upgrading to 2.2.7, the “Optimize database tables” function has not worked. The command will run without producing an error, but the table overhead does not change at all (confirmed in PHPMyAdmin). This is on PHP 7.2, if that makes any difference.
-
Same here. Also using PHP 7.2. I am going to abandon WPOptimize and give them a 1-star rating.
This is ridiculous that they seem not to be acknowledging this issue after such a long period of time. It was first reported at least a week, or more, ago.
- This reply was modified 5 years, 10 months ago by webifiedOne.
With version 2.2.7, the changelog says the plugin adopted a different method of optimization: Before, it was optimizing all the tables at once, and with the newer version, it attempts to optimize the tables one at a time instead, to reduce timeout errors. That’s the point where the problem occurred, so I assume that’s where the problem lies.
I wonder if it’s some kind of syntax issue, like what happens in PHPMyAdmin if you hit “optimize” without selecting any tables. No idea why they haven’t found it three sub-versions on, though.
Hi,
The command will run without producing an error, but the table overhead does not change at all
If the table is already optimized, then that’s the expected outcome. WP-Optimize runs the
OPTIMIZE
SQL command which asks the database server (i.e. MySQL / MariaDB) to optimize the on-disk table storage – https://dev.mysql.com/doc/refman/8.0/en/optimize-table.html. It’s then up to the server itself what it does with that; and the result can be “nothing”; the fact that there’s non-zero overhead doesn’t mean that that overhead will be removed if you issue anOPTIMIZE
command. Do you get a different result if you run the command manually in phpMyAdmin?To clarify, regarding:
Before, it was optimizing all the tables at once, and with the newer version, it attempts to optimize the tables one at a time instead, to reduce timeout errors
This only refers to whether the
OPTIMIZE
commands are issued in response to separate HTTP calls, or not. It’s still exactly the same SQL commands being issued (because, there is only one such command).David
- This reply was modified 5 years, 10 months ago by David Anderson.
Yes, I do get a different result in phpMyAdmin, and I got a different result in versions 2.2.6 and earlier of this plugin.
Typically, I have several tables (such as the WP options table) that incur substantial overhead over time and a few others with a very small amount of overhead — less than 1 KB. The total overhead for the whole database depends on how long it’s been since the last optimization, but is typically 45 KB or so after a day or two and several MB if it’s been longer.
The version of phpMyAdmin my host’s server uses has a command to select only tables with overhead for optimization or repair. You can also select all tables and run optimize, which will produce the same result, although it takes a bit longer. If I do that, it will remove all overhead, after which both phpMyAdmin and WP-Optimize will show zero overhead on all tables.
Earlier versions of WP-Optimize (2.2.6 and earlier) would remove most of the overhead. Occasionally, a very small amount would remain after optimization, but it was so incidental that it wasn’t a big deal (e.g., 76–128 bytes).
The current versions (2.2.7 and later) perform no table optimization. They don’t throw an error, but there is no change in reported overhead. For instance, I just checked now and WP-Optimize reported 83.2 KB overhead in Tables. I went to Optimizations and ran the optimize tables command. I then went back to Tables, clicked “Refresh Tables,” and saw that the reported overhead had not changed at all. phpMyAdmin shows the same thing, although I’m able to select the tables with optimize and remove it, which WP-Optimize no longer allows me to do.
This has been happening since 2.2.7, so something changed at that point that has effectively prevented any table optimization on at least some servers. Judging by the other comments, I’m not the only one experiencing that problem.
- This reply was modified 5 years, 10 months ago by Ate Up With Motor.
- This reply was modified 5 years, 10 months ago by Ate Up With Motor.
Indeed the plugin is now broken. I have already uninstalled it. It was good when it was working but now new updates just broke it for good.
I think I’ve found how this can happen… hang on…
You should now find this fixed in WP-O 2.2.11. @ate-up-with-motor thanks the info.
David
Okay, that seems to have worked. Notably, when the table optimization is running, it once again shows the name of the table it’s optimizing, which hadn’t been the case with previous updates since 2.2.7.
One minor remaining caveat: The table report doesn’t refresh (even if you hit “Refresh Tables”). After running the optimization, my first reaction naturally was to switch to the Tables tab and click “Refresh Tables” to see if the reported overhead had changed. Initially, it showed me that nothing had changed, even after I hit “Refresh Tables” several times. It was only after I switched to the Settings tab and then switched back to Database that the tables report updated correctly.
Hi,
We have just recently released an update. Can you try and check if you still get the same issue?
Regards,
BryleOptimization seemed to be working properly in 2.2.12 and still is in the new 2.2.13 update.
- The topic ‘Table optimization still doesn’t work in 2.2.10’ is closed to new replies.