WordPress stores its configuration by using key-value structure data that reside in the options table. By default named as wp_options or wp_<site-id>_options for multisite. This is a simple method that should use for simple data. This option data can be accessed directly through /wp-admin/options.php.
Optimise Database Query
To make it reduce query to the database for every single row, it has a field autoload, when set to “yes” all the data will be grouped in a single big chunk array called alloptions. Each time page is loaded, alloptions will use to get data instead of a query to the database. This is a good approach to makes WordPress faster, but when the size alloptions become bigger, this will crash a website when not enough memory to handle it.
Most plugins, by default, will use get_option and update_option to store their configuration that reflects the options table. WordPress transient also uses it. There is a good practice to remove the data when uninstalling the plugin and set an expiry time when using transient. But, not all plugins follow good practice. This is the big culprit when the size of alloptions too big to handle..
The ideal size is 1 MB and below. When using in-memory solutions like Memcached or Redis for persistent object caching, Memcached will limit it to 1 MB if no further configuration. Redis can handle larger than 1 MB but it can make it a little bit be slow because of operations serialize and unserialize the objects.
There is a misconception to handle this issue. Some advised setting autoload to “no” or other than “yes” will reduce alloptions size. By design, WordPress will treat all data autoloaded if no autoload is set to “yes”, which means still need one data set to “yes”.
Docket Cache has a different approach. Enabling “Suspend WP Options Autoload” options, Docket Cache will store non-prominent WordPress options to single data, including transient and other plugin data. This will ensure the size of alloptions small and no query to makes to the database.