Following the history on GitHub, it appears that this behaviour has existed since wp_load_alloptions() was introduced, 17 years ago. It was added as part of code that was introduced to address this ticket, and seems to be intended to fix issues related to object caching.
The full explanation for the entire change is given as:
(In [4855]) Introduce Notoptions and Alloptions caching, so that all options (and previously attempted Notoptions) are read from the cache in one go. Should reduce cache misses to zero or close to it. fixes #3726
To explain this a bit:
- Two pseudo-options are stored in the object cache (just there, not in the DB)
- ‘notoptions’ stores all attempted non-options so that the DB isn’t accessed more than once trying to load these options that don’t exist
- ‘alloptions’ stores all autoloaded options. The first time any option is queried, ‘alloptions’ will be populated (either from the DB,
or from a persistent object cache). If the option is in there (likely,
most options are autoloaded), it’ll be read from there. So you just
have one cache read for all your autoloaded options.- Non-autoloaded options revert to the options cache as before (one item per cache entry).
- Since the loading of the autoloaded options is used by get_option(), people using alternative object caches will no longer
see individual queries for each option on the first load (i.e. with an
empty object cache)All of this should be transparent. As long as you use get_option(),
add_option(), update_option(), and delete_option(), it should be like
nothing ever happened.This should reduce cache misses to zero (or close to it), and it
should reduce redundant queries.