Title: wp_options database table not optimized
Last modified: April 8, 2023

---

# wp_options database table not optimized

 *  Resolved [Skrlance](https://wordpress.org/support/users/seanlance/)
 * (@seanlance)
 * [3 years, 1 month ago](https://wordpress.org/support/topic/wp_options-database-table-not-optimized/)
 * The plugin doesn’t ask to optimize wp_options table database overhead. While 
   for everything else, it works perfectly!
 * Last time you told me that it may be due to limitation of inno database, but 
   I see that any other database optimizing plugin has optimized database overhead
   of my wp_options table.
 * I am not much knowledgeable in this case but I am just telling what I am seeing!
 * Kindly,
 * Can you fix this plz!

Viewing 1 replies (of 1 total)

 *  Plugin Author [Milan Petrovic](https://wordpress.org/support/users/gdragon/)
 * (@gdragon)
 * [3 years, 1 month ago](https://wordpress.org/support/topic/wp_options-database-table-not-optimized/#post-16640314)
 * There is no way actually to optimize this table in most cases. This table is 
   very often used for reading and writing, it is relatively small and almost always
   in a fragmented state. My plugin has thresholds to consider a table fragmented(
   size and degree of fragmentation), and it has 3 different methods for optimization(
   you can try each one by changing it in the plugin settings).
 * I have tested all plugins for optimization in the past few years, and all the
   plugins are using the same optimization method (there is no other way to do it,
   really), and they all have the same results.
 * When you run optimization, MySQL always reports that it is done. After that, 
   it is often reporting incorrectly what has actually happened, because it uses
   an internal cache and it very rarely actually gets accurate statistics. My plugin
   does trigger statistics refresh after optimization to try and get accurate results.
 * Finally, there is no real need to always optimize every table; that is often 
   a bad idea. Big fragmentation can slow down big tables; small tables are always
   fragmented because that is how MySQL works. MySQL works in size increments, so
   if your table is 2MB, MySQL still has to reserve at least 4MB, making the table
   fragmented by default.
 * I know for a fact that some plugins report the optimization for this table incorrectly
   on purpose, and I choose not to do that, and my plugin shows the statuses as 
   they are, it is even trying to refresh statistics anytime it can to force MySQL
   to give better results.
 * Milan

Viewing 1 replies (of 1 total)

The topic ‘wp_options database table not optimized’ is closed to new replies.

 * ![](https://ps.w.org/sweeppress/assets/icon.svg?rev=2889279)
 * [SweepPress: Website Cleanup and Optimization](https://wordpress.org/plugins/sweeppress/)
 * [Frequently Asked Questions](https://wordpress.org/plugins/sweeppress/#faq)
 * [Support Threads](https://wordpress.org/support/plugin/sweeppress/)
 * [Active Topics](https://wordpress.org/support/plugin/sweeppress/active/)
 * [Unresolved Topics](https://wordpress.org/support/plugin/sweeppress/unresolved/)
 * [Reviews](https://wordpress.org/support/plugin/sweeppress/reviews/)

 * 1 reply
 * 2 participants
 * Last reply from: [Milan Petrovic](https://wordpress.org/support/users/gdragon/)
 * Last activity: [3 years, 1 month ago](https://wordpress.org/support/topic/wp_options-database-table-not-optimized/#post-16640314)
 * Status: resolved