物化视图快速刷新比全量刷新更吃TEMP，因其需构建变更日志、增量合并、哈希连接和排序等操作，均依赖TEMP；而基表或MLOG$缺索引、PGA过小、并行刷新等会加剧TEMP消耗。
物化视图刷新（尤其是快速刷新）会大量申请临时段，不是因为“写数据”，而是因为要构建变更日志（MLOG$）、做增量合并、执行哈希连接和排序——这些操作全依赖 TEMP。
物化视图快速刷新为什么比全量刷新更吃 TEMP
快速刷新（DBMS_MVIEW.REFRESH with method => 'F'）看似轻量，实则内部要：读取物化视图日志（MLOG$ 表）、关联基表、去重、排序、计算增量 delta、再 merge 回物化视图。整个链路里多个环节都会触发磁盘排序或哈希溢出。
- 基表没索引时，
MLOG$和基表 JOIN 无法走索引嵌套循环，优化器大概率选哈希连接 → 每个并行进程都独立分配哈希区，总 TEMP 消耗翻倍 -
MLOG$中的SEQUENCE$$或SNAPTIME$$字段未建索引，导致刷新时需全扫日志表 + 排序，ORDER BY直接落盘 - 刷新语句隐含
GROUP BY（如聚合物化视图），而PGA_AGGREGATE_TARGET设置过小（例如仅 512MB），内存不够就强制 spill 到 TEMP - 并发刷新多个物化视图时，每个会话各自申请临时段，但 Oracle 不共享 TEMP 段，总量线性叠加
如何确认是物化视图刷新在占 TEMP
别只看 SQL 文本，重点查 v$sort_usage 关联正在运行的刷新会话：
- 执行
SELECT s.sid, s.sql_id, u.segtype, u.blocks * 8 / 1024 AS mb_used FROM v$session s, v$sort_usage u WHERE s.saddr = u.session_addr AND s.program LIKE '%DBMS_MVIEW%' - 若
segtype = 'SORT'且mb_used > 500，基本可锁定是该会话的刷新操作在排序 - 用
SELECT sql_text FROM v$sql WHERE sql_id = '<上面查到的sql_id>'看是否含MV_REFRESH或INSERT /*+ APPEND */ INTO <mv_name>类型语句
绕过 TEMP 暴涨的实操调优点
核心是让刷新过程尽量避免排序和哈希，转向索引驱动的嵌套循环：
- 确保物化视图日志（
MLOG$）上至少有(SEQUENCE$$, SNAPTIME$$)的复合索引；没有就加：CREATE INDEX mlog$_t1_idx ON mlog$_t1(sequence$$, snaptime$$) - 刷新前手动收集基表统计信息：
DBMS_STATS.GATHER_TABLE_STATS('SCHEMA', 'BASE_TABLE')，避免优化器误估行数导致错误选择哈希连接 - 禁用并行刷新：
DBMS_MVIEW.REFRESH(..., parallelism => 0)；并行虽快，但 TEMP 是倍增的，单线程反而更稳 - 对聚合物化视图，检查是否真需要快速刷新；如果变更频率低，改用
method => 'C'（完全刷新）+ 分区交换，反而更省 TEMP
TEMP 已爆满时的紧急处理
别删文件、别 resize —— 物化视图刷新中的临时段不会释放，直到会话结束。此时最有效的是中断源头：
- 先查刷新会话：
SELECT sid, serial#, username, program FROM v$session WHERE program LIKE '%DBMS_MVIEW%' - 立即 kill：
ALTER SYSTEM KILL SESSION 'sid,serial#'；杀掉后，对应v$sort_usage记录几秒内消失，TEMP 空间立刻可重用 - 若 kill 后仍不释放，说明有未提交事务锁住日志表；查
v$transaction找start_time很老的事务，必要时ALTER SYSTEM KILL SESSION ... IMMEDIATE - 之后再重建 TEMP 表空间（新建 → 切换默认 → drop 旧的），否则下次刷新还会卡在同样位置
物化视图刷新的 TEMP 飙升，本质是“可控的中间计算开销”失控了——它不像普通 SQL 那样容易通过加索引一招解决，必须同时盯紧日志结构、统计信息、PGA 设置和并行度四个变量。最容易被忽略的是：MLOG$ 表本身也是普通堆表，没人给它建索引，结果每次刷新都在全表扫描+排序。
