先纠正一个常见误解：逻辑复制槽必须建在有写权限、wal_level=logical 的实例上，只读实例建不了槽，所以订阅源头只能是主库。担心解码吃主库 CPU，解法不是把槽挪到只读库，而是把消费端挪走，主库只负责产 WAL。主备切换后订阅会断一段，靠槽和 confirmed_flush_lsn 从断点续，千万别重建订阅，重建等于全量重来。切换窗口内 DDL 要停，订阅端 schema 对不上会直接卡死。监控盯 pg_replication_slots 的 lag 和 active，lag 涨到几百 MB 就该告警，别等 WAL 把磁盘撑满。... 展开详请

慢查询突增九成是执行计划切换，PG 的定位思路比 MySQL 直接——它自带执行计划的证据链：1. 先确认是计划变化：pg_stat_statements 里找到变慢的那条 SQL，对比历史执行时间。然后用 EXPLAIN（不是 EXPLAIN ANALYZE，先无副作用看计划）看当前计划——如果之前是 Index Scan 现在变成了 Seq Scan，或者 Join 方式从 NestLoop 变 HashJoin，就实锤了；2. 找计划变化的诱因：a. 统计信息过期：autovacuum 的 analyze 没跟上数据变化（大表批量导入后统计信息还是旧的），看 pg_stat_all_tables 的 last_analyze 时间，手动 ANALYZE 一次对比计划是否恢复；b. 数据分布变化：表数据量跨过了优化器的成本估算拐点（原来 10 万行走索引快，现在 100 万行全扫更快——但估算没跟上实际）；c. 参数变化：random_page_cost 调整、内存参数变更、版本升级导致的估算模型变化；3. 应急恢复：a. 手动 ANALYZE 更新统计信息（最常见且最安全的第一反应）；b. 仍不恢复就用 pg_hint_plan 或改写 SQL 强制索引（OFFSET 0 或 WHERE 条件改写）；c. PG 12+ 的最小恢复手段：把旧计划固化——用 pg_store_plans 或对 PG 15+ 用 explain 的 generic plan，或干脆 CREATE EXTENSION pg_hint_plan 加 hint 注释；4. 长期防复发：a. 对关键 SQL 建「计划回归监控」：定时对 Top SQL 跑 EXPLAIN（COSTS）并对比计划哈希，变化告警——计划变化比慢查询告警早一步；b. autovacuum_analyze_scale_factor 按表定制（大表调小，让 analyze 更勤）；c. 关键报表场景考虑 PG 的 JIT 关闭（JIT 对复杂查询偶尔选错计划）。PG 的优势是这一切都有系统视图可查：pg_stat_activity 看当前慢在哪、pg_stat_statements 看历史、pg_stat_user_tables 看 analyze 时间——定位链完整，不像有的数据库要靠猜。... 展开详请

由于 PostgreSQL 的 MVCC 机制： 当前云数据库已默认开启 autovacuum 配置参数，内核会自动回收过期数据，因此已用存储空间会在系统回收过期数据后自动释放出来。用户也可以手动执行 VACUUM 命令来回收过期数据（执行该命令后存储空间统计并不会立即下降，而是会把这些过期数据回收并标记为可重复利用）。如果想完全清理数据，可考虑使用带参数的 VACUUM FULL 命令（该命令会锁表，强烈建议只在维护期间使用）。 nVACUUM 命令使用请参见 PostgreSQL 官方文档。... 展开详请