A query that used the right index all week starts using a different one on Thursday morning, nothing was deployed, and ANALYZE TABLE puts it back. Before 5.6, InnoDB estimated index cardinality by sampling a handful of random pages and re-sampled whenever the server restarted or the table changed by more than a tenth — so the numbers the optimiser planned from moved on their own.
-- 5.6 defaults; confirm rather than assume
SHOW GLOBAL VARIABLES LIKE 'innodb_stats_persistent%';
-- innodb_stats_persistent ON
-- innodb_stats_persistent_sample_pages 20
-- innodb_stats_auto_recalc ON
-- per table, for one created before the upgrade
ALTER TABLE orders STATS_PERSISTENT=1, STATS_SAMPLE_PAGES=64;
ANALYZE TABLE orders;
-- and the estimates are now rows you can read
SELECT stat_name, stat_value
FROM mysql.innodb_index_stats
WHERE table_name = 'orders' AND index_name = 'idx_customer_placed';Persistent statistics live in mysql.innodb_table_stats and mysql.innodb_index_stats and survive a restart, so the plan stops depending on when the server last came up. That is the whole benefit and it is a large one: the plan now changes when somebody runs ANALYZE TABLE, which is a line in a deployment script rather than an event at four in the morning. Tables created before the upgrade keep the old behaviour until they are altered, which is the usual reason the variable reads ON and nothing has changed. STATS_SAMPLE_PAGES is for a table where twenty pages genuinely misrepresent the distribution — a higher value makes ANALYZE slower and the estimate better, and is worth setting only on the table whose plan you are arguing with.