V$SORT_USAGE查不到正在跑的SQL，因其不包含sql_id字段、仅记录已溢出到磁盘的排序且非实时，而V$TEMPSEG_USAGE才支持sql_id和segtype实时关联会话与语句。
为什么 V$SORT_USAGE 查不到正在跑的 SQL？
V$SORT_USAGE 只记录「已溢出到磁盘」的排序操作，且只在排序实际写入临时表空间时才写入。如果排序完全在内存（PGA_AGGREGATE_TARGET 足够）完成，这个视图就为空；如果 SQL 已执行完但临时段还没被 SMON 回收，它也可能残留旧记录——不是实时视图。
更关键的是：该视图不包含 sql_id 字段，只提供 session_addr 和 sql_hash_value（11g 及以前），而 sql_hash_value 在 12c+ 中已弃用，无法直接关联到当前执行的 SQL。
所以别指望靠它定位“谁在跑大排序”，它更适合做事后回溯或配合其他视图交叉验证。
V$TEMPSEG_USAGE 才是真正能查实时占用的视图
从 12c 开始，V$TEMPSEG_USAGE（或全局版 GV$TEMPSEG_USAGE）才是诊断临时段占用的首选。它覆盖所有临时段类型：SORT、HASH、LOB_TEMPORARY，且字段含 sql_id 和 segtype，可直接绑定会话与语句。
注意必须关联 dba_tablespaces 获取真实块大小，不能硬写 8192：
SELECT s.sid, s.serial#, s.username, t.sql_id, t.segtype,
t.blocks * tb.block_size / 1024 / 1024 AS mb_used
FROM v$tempseg_usage t
JOIN v$session s ON t.session_addr = s.saddr
JOIN dba_tablespaces tb ON t.tablespace = tb.tablespace_name
WHERE tb.contents = 'TEMPORARY';
-
segtype = 'SORT'表示 ORDER BY/GROUP BY 等导致的磁盘排序 -
segtype = 'HASH'多见于大表 HASH JOIN 或 HASH GROUP BY -
blocks是 Oracle 数据块数，必须乘tb.block_size才准，硬编码 8192 在非默认块大小库中会严重失真
查到高占用 SQL 后，怎么确认是不是它真在跑？
拿到 sql_id 后别急着 kill，先看它是否还在执行中：
检查 v$session 状态：
SELECT sid, serial#, status, sql_id, prev_sql_id, event FROM v$session WHERE sql_id = 'xxx';
- 若
status = 'ACTIVE'且event是direct path write temp或db file sequential read（读临时文件），说明确实在写 TEMP - 若
status = 'INACTIVE'但prev_sql_id匹配，大概率是刚执行完，临时段尚未释放——此时查v$temp_extent_pool.bytes_cached更有意义 -
v$sort_usage的sql_id实际对应的是v$session.prev_sql_id，不是当前sql_id，这点极易搞错
临时表空间“满”但 V$TEMPSEG_USAGE 为空？盯 v$temp_extent_pool
这是最常被忽略的坑：临时表空间显示 100% 使用，但 v$tempseg_usage 查不到任何活跃会话，基本可断定是孤立临时段（已分配未回收）。
立刻查这两个指标：
-
v$temp_extent_pool.bytes_cached：持续高位（比如几 GB）且不随会话退出下降 → 孤立段典型特征 -
v$temp_space_header.free_blocks：这才是物理空闲块数，用它算出的free_mb才是真实可用空间
此时执行 ALTER TABLESPACE temp COALESCE; 或触发 DBMS_SPACE_ADMIN.TEMP_TABLESPACE_DROP_SEGMENTS 更有效，而不是杀会话或重启实例。
