问TencentDB for PostgreSQL 慢查询突增，如何定位执行计划变化？

场景：业务使用腾讯云 TencentDB for PostgreSQL，版本 14，一张订单表约 8000 万行，按用户 ID 和创建时间范围查询最近订单，已经建了 (user_id, created_at) 的联合索引。 现象： 1. 昨天开始，这个查询的耗时从几十毫秒涨到几秒，慢查询日志里大量出现。 2. 用 EXPLAIN 看，部分参数下走了顺序扫描，而不是索引扫描，同一条 SQL 换一个 user_id 又会走索引。 3. 前一天晚上做过一次大批量的历史数据归档删除，之后才开始变慢。 已尝试： 1. 手动执行了 ANALYZE，变慢的情况有所缓解，但没有完全恢复。 2. 查看了 pg_stat_user_tables，发现该表的死元组数量很高，不确定 autovacuum 是否来得及处理。 3. 没有开启 auto_explain，也没有保留变慢前的执行计划作对比。 想请教： 1. 大批量删除之后，统计信息和死元组对执行计划选择有哪些影响？应该如何判断是统计信息过期还是表膨胀？ 2. 在云数据库上，如何查看 autovacuum 的运行情况和相关参数，是否可以针对大表单独调整阈值？ 3. 如何用 EXPLAIN (ANALYZE, BUFFERS) 区分是索引选择问题还是 IO 问题？有没有办法保留历史执行计划以便对比？ 4. 大批量归档删除应该怎样分批执行，才能降低对线上查询的影响？