主备切换后聚合查询变慢，主因是新主库索引页未载入内存、查询计划缓存清空或缓冲池未预热，导致GROUP BY等操作反复读盘；需验证索引存在性、检查执行统计中docsExamined与executionTimeMillis变化，并用带hint的轻量探针查询预热热路径。
主备切换后聚合查询变慢，大概率不是SQL本身有问题，而是新主库的索引页没载入内存、查询计划缓存被清空，或WiredTiger/InnoDB缓冲池未预热——这些不会报错，但会让GROUP BY、SUM()、COUNT(DISTINCT)类查询反复读盘、重建执行计划。
查备库是否真有对应索引
切换后新主库可能缺失部分索引（尤其后台建索引未完成、或从库启用了skip_slave_start跳过复制期间的DDL）。聚合查询若依赖WHERE + GROUP BY联合索引，缺索引会直接退化为全表扫描。
- 在新主库上运行
db.collection.getIndexes()（MongoDB）或SHOW INDEX FROM table_name（MySQL），确认status、createdAt等常用过滤+分组字段的复合索引是否存在 - 注意MySQL中
ALTER TABLE ... ADD INDEX若在备库执行失败（如磁盘满、锁冲突），错误日志可能被忽略；检查SHOW SLAVE STATUS\G中的Seconds_Behind_Master和Last_SQL_Error - MongoDB 4.2+ 支持后台建索引（
{ background: true }），但切换前未完成的索引在新主库上仍不可用，需手动补建
别信explain("executionStats")里“winningPlan”就代表快
刚切换完的节点，即使explain显示走索引，executionStats.totalDocsExamined也可能异常高——因为索引B-tree根节点在内存，但中间层和叶子页还在磁盘，每次访问都要触发一次4KB页面加载。
- 对比切换前后同一查询的
executionStats.executionTimeMillis和executionStats.docsExamined：若后者不变但前者翻倍，基本可断定是缺页（page fault）导致 - 避免用
.count()验证索引是否生效——它不加载文档页，无法触发索引页预热；改用.findOne().hint({ a: 1, b: -1 })显式走索引并拉取真实数据 - PostgreSQL用户注意：
EXPLAIN (ANALYZE, BUFFERS)里的Shared Hit占比低于60%时，说明缓存未暖
缓存预热不能靠刷SELECT COUNT(*)
盲目遍历全表或执行空聚合，对WiredTiger（MongoDB）、InnoDB Buffer Pool（MySQL）、shared_buffers（PostgreSQL）几乎无效——缓存管理按页面粒度，且聚合查询真正需要的是索引路径上的分支页 + 分组键所在的数据页，不是整行记录。
- 提取慢查询日志中高频出现的
filter和group组合，例如{ region: "east", status: "done" }+{ $group: { _id: "$category", total: { $sum: "$amount" } } } - 对每个组合构造轻量探针查询：
db.orders.aggregate([ { $match: { region: "east", status: "done" } }, { $group: { _id: "$category", total: { $sum: 1 } } }, { $limit: 1 } ]).hint({ region: 1, status: 1, category: 1 }) - 容器环境必须检查数据库实际可用缓存：MongoDB看
db.serverStatus().wiredTiger.cache["bytes currently in the cache"] / wiredTigerCacheSizeGB；MySQL看SHOW ENGINE INNODB STATUS里的Buffer pool hit rate，持续低于990/1000就是缓存不足
最易被忽略的一点：应用连接池往往在切换后立即发起大量聚合请求，而数据库缓存是逐页加载的。如果没做请求节流或预热探测，头10分钟的P99延迟会远高于均值——这不是故障，是机制使然，得用探针查询把“热路径”提前打进去，而不是等业务流量把它撞热。
