物化视图删不干净需先查 pg_class 和 pg_depend；残留源于未清理的索引、约束、临时表或共享依赖，CASCADE 仅删直系依赖，须手动处理非 n / a 类型依赖及 pg_temp_表，并避免直接修改系统表。
物化视图删不干净？先查 pg_class 和 pg_depend
直接执行 drop materialized view xxx 后，表名还能在 d 或 pg_tables 里看到，说明底层对象没清完。postgresql 的物化视图本质是带数据的普通关系（relkind = 'm'），但可能残留索引、约束、依赖序列或统计信息。别急着重试，先确认它是否真被删了：
select relname, relkind from pg_class where relname = 'xxx'; 如果还有记录，说明 drop 没生效或被事务中断；如果没了，但 pg_depend 里还挂着依赖项，就属于“逻辑残留”——后续建同名对象时会报 relation "xxx" already exists 或触发权限异常。
DROP MATERIALIZED VIEW …… CASCADE 不等于“全清”，得盯住依赖链
CASCADE 只自动删直系依赖（比如物化视图上的唯一索引、主键约束），但不会碰外部对象：比如你用 REFRESH MATERIALIZED VIEW CONCURRENTLY 时自动生成的临时日志表（pg_temp_* 前缀）、手动加的 COMMENT、或者通过 CREATE RULE 绑定的重写规则。这些都得手动处理：
- 检查依赖：
SELECT refobjid::regclass, deptype FROM pg_depend WHERE objid = 'xxx'::regclass; - 删掉非
n（normal）或a（auto）类型的依赖，比如i（internal）可能是系统生成的临时结构，e（extension）需从扩展层面清理 - 删完再跑一次
ANALYZE pg_class，避免缓存导致元数据不一致
并发刷新留下的“幽灵表”怎么识别和清理
用 CONCURRENTLY 刷新过物化视图后，PostgreSQL 会在后台建一张临时表（形如 pg_temp_12345）做数据比对，正常流程下它该自动消失。但如果刷新中途崩溃或连接断开，这张表就卡在 pg_class 里，类型为 r（普通表），relnamespace = pg_my_temp_schema()。它不显示在 dt，但会占着 OID 和磁盘空间：
- 定位：
SELECT relname FROM pg_class WHERE relnamespace = pg_my_temp_schema() AND relname LIKE 'pg_temp_%'; - 确认无活跃会话用它：
SELECT * FROM pg_stat_activity WHERE backend_type = 'client backend' AND state = 'active';（重点看是否有长事务关联该 schema） - 安全清理：
DROP TABLE IF EXISTS <code>pg_temp_xxx; —— 注意必须显式指定 schema，不能只写表名
误删后恢复困难，关键点在 pg_depend 和 pg_shdepend 的交叉引用
真正难搞的是跨数据库或跨角色的残留：比如物化视图属于某个 extension（如 postgis），或者被其他数据库对象（如函数、视图）通过 SECURITY DEFINER 引用。这时候 pg_depend 里会出现 pg_shdepend 关联的共享依赖项，删不掉会报 cannot drop object because it is required by the database system。这种情况下：
- 先查共享依赖：
SELECT dbid, classid::regclass, objid, objsubid, refclassid::regclass, refobjid FROM pg_shdepend WHERE objid = 'xxx'::regclass; - 若
refclassid是pg_database或pg_authid，说明权限或数据库级绑定存在，得先改对应对象的SECURITY DEFINER属性或ALTER DATABASE …… OWNER - 切勿直接删
pg_depend记录——破坏依赖链会导致整个集群元数据损坏
最麻烦的不是命令记不住，是删之前没意识到物化视图背后可能连着三层依赖、两个 extension、一个临时 schema 和一套自定义统计函数。动手前花三十秒查 pg_depend，比事后重建省三小时。
