WordPress
wp_options
wp_options is the database table where WordPress stores site-wide settings and many plugin settings as name and value pairs. It is read on every request.
How it is measured
Columns are option_id, option_name, option_value, and autoload. Core entries include siteurl, home, blogname, active_plugins, permalink_structure, cron, and rewrite_rules. Values may be serialized PHP arrays. Read with get_option(), write with update_option(), or use wp option get and wp option update.
Measure it with SELECT COUNT(*), SUM(LENGTH(option_value)) FROM wp_options, then split by autoload. wp db query can run that, and wp option list --orderby=size_bytes shows the largest rows.
Worked example
A travel agency's wp_options table has 31,000 rows and weighs 96 MB. 24,000 of the rows are named like _transient_feed_ and _site_transient_, left by a news widget that never expired its caches. The remaining 7,000 include the cron option at 480 KB.
Deleting the expired transients with wp transient delete --expired and clearing a runaway cron list drops the table to 6 MB. Admin loads fall from 3.1 to 1.4 seconds.
How it differs
wp_options is the table, and autoload is one of its columns that decides which rows load into memory every request. A row with autoload off still counts toward table size but not toward per-request cost. The table also differs from wp-config.php, since options can be edited in wp-admin or by plugins while the config file cannot.
Common errors
Running search-replace on serialized values with plain SQL. Changing siteurl or home to a wrong address and locking yourself out. Storing large blobs with autoload on. Deleting a row you do not recognize. Editing the cron option by hand.
In practice
Sort the table by size, check which ones are autoloaded, and map the top 20 to plugins you still use. Back up before deleting anything. If a site address is wrong, override it with WP_HOME and WP_SITEURL in wp-config.php.