企业官网建设流程全解析

简介：某银行DB2生产系统SQL执行时间急剧变长、活跃会话数持续高位，排查后最终锁定系统临时表空间TEMPSPACE1膨胀至10GB这一根因。这份doc文档面向DBA与性能优化人员，完整记录了问题从发现、监控指标分析、常规资源排除，到LATCH等待分析、堆栈收集、利用db2trc工具挂起实例抓取证据的整个诊断过程，并给出优化SQL、调整临时表空间配置等可落地的解决措施。作者为IBM认证高级DBA，案例来自真实运维一线，涉及db2top、db2pd -latch、stack及db2trc suspend等实操手段，例如用db2trc在临时表空间达到阈值时暂停实例，捕捉关键状态，既演示了系统性排查思路，也适合DBA直接借鉴。资源为1个doc文件，压缩包仅607KB，内容精炼集中；目前已有5899人学习下载，认可度较高。

1. 临时表空间吃满，SQL为什么全线卡顿

跑批任务在凌晨两点准时开始，某数据平台的例行汇总作业往常四十分钟跑完，这天两个小时还没结束。登上去一看，系统临时表空间用量飙到几十GB，数据库的排序和哈希连接全部挤在临时盘上，业务侧的查询排队时间肉眼可见地拉长。这不是偶发故障，而是DB2系统临时表空间过大引发的典型性能问题：临时空间本身不具业务语义，但它的膨胀速度直接决定了SQL能不能跑完、跑得多快。

这类问题最难受的地方是——表空间看起来“没坏”，文件没满，告警也没触发，可数据库整体就是慢。本文围绕系统临时表空间从机制、定位、处理到预防完整讲一遍，包括排查命令、参数选择、以及那些会让问题从“一次故障”变成“反复翻车”的认知坑。适合正在处理DB2性能问题的DBA、给客户做数据平台运维的工程师，以及被临时表空间困扰过的应用开发同学。

2. 先从机制上搞清：DB2系统临时表空间到底做什么的

2.1 系统临时表空间和数据临时表空间的差别

DB2里的临时表空间分两类：系统临时表空间（System Temporary Tablespace）和用户临时表空间（User Temporary Tablespace）。名字容易混，但用途完全不同。系统临时表空间是数据库内部自动使用的，排序（sort）、哈希连接（hash join）、重组索引、物化查询表、SQL中的OLAP函数（如ROW_NUMBER、RANK）都可能往这里写中间结果。用户临时表空间则是应用显式创建临时表用的，比如DECLARE GLOBAL TEMPORARY TABLE。

日常出问题的基本都是系统临时表空间。创建数据库时默认会生成一个名为TEMPSPACE1的系统临时表空间，初始大小通常不大。当并发查询多、排序量大、或者某条SQL的哈希连接需要把大量中间行写入临时空间时，使用量会迅速上涨。很多人以为“临时”就是随便用用无所谓，实际上它是SQL执行计划能否成立的关键资源——一旦临时空间满了，SQL会直接报SQL0964C，事务回滚，跑批中断。

这里还有一个容易混淆的点：数据表空间里也有TEMP文件的概念，但那是缓冲区或工作文件，与临时表空间不是一回事。做排查时先确认对象——查的是SYSCAT.TABLESPACES里TBSPACE TYPE为'T'的空间，而不是数据表空间。方向错了，后面所有结论都是错的。

系统临时表空间默认只有一个实例级别的副本。如果数据库启用了多温度（multi-temperature）存储或分区数据库，临时表空间可能有多个容器分布在不同目录或不同节点上。DBA观察时不能只看总大小，还要看每个容器是否均匀增长——某个容器增长异常快，往往代表IO局部热点，比总空间满了更隐蔽。

2.2 临时表空间使用量的水位线怎么看

判断系统临时表空间是否过大，不能只看配置大小，要看当前使用量相对配置的占比，以及增长趋势。DB2中有几个现成的视角：实例快照的TOTAL_SORT_TIME和SORT_OVERFLOWS能反映排序溢出情况；表空间快照里的USED_PAGES和MAX_USED_PAGES能反映临时表空间的峰值使用；db2pd命令则能看到实时的容器使用。

常见操作是先用db2pd看当前使用量，再结合快照看峰值：

db2pd -d sample -tablespaces # 关注输出中的字段： # Tablespace ID=2 Name=TEMPSPACE1 # Type=System temporary # Current Used Pages=51200 # Max Used Pages=89000

这段命令的作用是实时查看表空间级别的使用页数。Current Used Pages是当前使用的页数，Max Used Pages是自激活以来的最大使用页数。如果Max远大于Current，说明曾经出现过高水位；如果Current持续处在高位且不回落，说明临时空间的占用是持续性的，不是瞬时峰值。页数乘以页大小，就能换算成实际字节数。

db2 get snapshot for tablespaces on sample | grep -E "Tablespace Name|Total Pages|Used Pages|Max Used Pages"

快照命令的作用是看历史累积信息。Total Pages是表空间配置的总页数，Used Pages是当前使用，Max Used Pages是激活以来拍到的最大值。两处数字交叉验证，基本能判断：是单次语句瞬时吃满，还是并发累积导致长期高位。

还有一条更直接的SQL，查询SYSCAT视图拿静态信息，适合做定期巡检：

SELECT TBSPACE, TBSPACEID, PAGESIZE, EXTENTSIZE, TOTAL_PAGES, USED_PAGES, FREE_PAGES FROM SYSCAT.TABLESPACES WHERE TBSPACE TYPE = 'T';

这条SQL看了什么：TBSPACEID用于对应db2pd里的表空间ID，TOTAL_PAGES是设置上限，USED_PAGES是当前占用。注意这里是“设置上限”而不是“文件系统实际可用”，如果文件系统所在盘比表空间上限小，填满表空间之前可能先把盘写满，那是另一类故障。

判断“过大”，我一般看两个阈值：使用率超过配置大小的70%，或峰值使用量超过20GB且出现在TPS超过基线的时段。两种情况处理思路不同——前者需要扩容，后者需要抓SQL。只有用量数据而没有业务时间线，很难判断该扩还是该收。

3. 定位膨胀源头：三个命令找出是谁在吃临时表空间

3.1 第一步：先确认是单条SQL还是并发累积

临时表空间上涨通常有两种形态：一条SQL吃掉几十GB直接撑爆，或者几十条SQL都吃几百MB叠加起来把空间磨到高位。处理策略完全不同。前者是抓主线SQL的语句级临时空间消耗，后者要考虑整体并发和workload管理。

判断方法是用监控表函数查询活动语句的临时空间使用：

SELECT SUBSTR(STMT_TEXT, 1, 60) AS STMT, SESSION_USER, TOTAL_SORT_TIME, SORT_OVERFLOWS, TEMP_TABLESPACE_TOP, WORK_ACT_TIME, ROWS_READ, ROWS_RETURNED FROM TABLE(MON_GET_ACTIVITY(NULL, -1)) AS T ORDER BY TEMP_TABLESPACE_TOP DESC FETCH FIRST 10 ROWS ONLY;

这段SQL的结果顺序已经按临时空间峰值使用量排好。TEMP_TABLESPACE_TOP的单位是页，乘以页大小就是字节。SORT_OVERFLOWS如果大于0，说明排序溢出到了临时空间，这代表排序堆不够用。注意MON_GET_ACTIVITY只能看到正在执行的或最近结束的活动，如果问题SQL已经跑完但临时空间还是满的，需要转向MON_GET_TABLE去查哪些表被大量读写到临时空间。

拿到TEMP_TABLESPACE_TOP后，用db2pd回顾历史语句：

db2pd -d sample -activities top=10

这条命令展示当前活动语句按资源消耗排序的结果。对于已经跑完但曾经吃爆临时表空间的SQL，db2pd的activities输出有限，完整语句要从package cache里捞。两者的配合方式是：先用MON_GET_ACTIVITY定位当前正在消耗的语句，再用pkg cache的语句文本做后续分析。

还有一种常见情况是仪表盘和监控平台没有配workload事件，语句执行完就查不到临时表空间占用了。这时可以在监控表函数上补一个运行中的采样：

SELECT ACTIVITY_ID, SUBSTR(STMT_TEXT, 1, 100) AS STMT, TEMP_TABLESPACE_TOP FROM TABLE(MON_GET_ACTIVITY(NULL, -1)) WHERE TEMP_TABLESPACE_TOP > 0

加了WHERE条件后能过滤出真正用过临时空间的语句，避免被海量小查询刷屏。TEMP_TABLESPACE_TOP > 0意味着这条SQL的排序或哈希连接占用了临时表空间，而不是走内存路径。如果结果集为空，说明当前时刻没有语句正在大量使用临时空间，问题时段已过，需要抓历史。

3.2 第二步：从package cache抓历史语句的临时空间消耗

活跃语句抓完了，如果没抓到或者抓到的语句不是最凶的那个，去package cache看历史。DB2的package cache会缓存编译过的语句，附带执行统计信息。查询方式：

SELECT SUBSTR(STMT_TEXT, 1, 80) AS STMT_TEXT, NUM_EXECUTIONS, TEMP_TABLESPACE_TOP, TOTAL_SORT_TIME, SORT_OVERFLOWS FROM TABLE(MON_GET_PKG_CACHE_STMT(NULL, NULL, NULL, -1)) AS T ORDER BY TEMP_TABLESPACE_TOP DESC FETCH FIRST 20 ROWS ONLY;

这段SQL的作用是从package cache中捞取历史语句的执行统计，按临时表空间峰值排序。TEMP_TABLESPACE_TOP依然是页数，SORT_OVERFLOWS表示排序溢出次数。NUM_EXECUTIONS如果很大但TEMP_TABLESPACE_TOP很小，说明这条语句不怎么吃临时空间；反过来，NUM_EXECUTIONS为1、TEMP_TABLESPACE_TOP非常大，就是一个高频低效的独立事件。

排完序后，观察前几条语句的共性：是不是都出现在某几张表上？是不是都用了DISTINCT、GROUP BY、ORDER BY、OLAP函数？有没有跨大表的连接且连接列没有索引？这三类情况几乎覆盖了DB2临时表空间暴涨的绝大多数场景。

抓出来的语句还要区分是“单次执行临时空间大”还是“多次执行累积大”。前者看TEMP_TABLESPACE_TOP，后者要将TEMP_TABLESPACE_TOP乘以NUM_EXECUTIONS估算总消耗。一个典型的陷阱是：某条语句单次峰值不高，但每秒钟执行几十次，临时空间一直在被小批量占用，表空间水位下不去。这种问题单独优化一条SQL无效，必须从应用侧减少执行频率或改走汇总表。

拿到语句文本后，在测试环境执行EXPLAIN，看访问计划里有没有SORT或HSJOIN节点，一步到位确认问题点：

db2expln -d sample -q "SELECT ..." -terminal

db2expln输出的计划中，SORT节点代表排序操作，HSJOIN代表哈希连接。这两个节点是否把中间结果写到临时表空间，取决于排序堆和哈希堆大小。EXPLAIN能看到计划形态，但不能直接看到物理的临时空间页数消耗，要和上面的监控数据配合才有意义。

3.3 复现与确认：共享变量和排序堆的真实影响

SQL抓出来后，最后要验证的是参数层面的影响。DB2的系统临时表空间使用量受sortschema相关的排序堆参数约束——SHEAPTHRES和SORTHEAP。排序操作先在SORTHEAP里做内存排序，内存不够时溢出到临时表空间。SHEAPTHRES是实例级阈值，限制所有排序堆总和；SORTHEAP是单条语句的排序堆上限。这两个参数直接影响临时表空间的使用强度。

复制现场SQL做验证时，通过改SORTHEAP观察临时空间用量变化：

db2 connect to sample db2 update db cfg for sample using SORTHEAP 1024 db2 terminate

这里把SORTHEAP从默认的256调整到1024，是为了验证排序溢出是否减少、TEMP_TABLESPACE_TOP是否下降。调整后重跑SQL，对比前后两次的SORT_OVERFLOWS和TEMP_TABLESPACE_TOP。SORT_OVERFLOWS如果归零，说明排序全在内存完成，临时表空间压力解除。

需要注意的一个坑是：SORTHEAP是指私有排序堆还是共享排序堆，取决于数据库版本和配置方式。旧版本中排序堆往往以私有内存方式为每个排序分配，新版本引入了共享排序的概念。验证的方式是看实例快照里的SharedSort和PrivSort指标，哪个高就调整对应的参数。不能只看SORTHEAP这一个名字就断定管用。

复现现场的时候，整理一份完整的对比记录是排查能否收尾的关键。下面这张表是我常用的记录模板：

并发和高水位时期的SHEAPTHRES设置，往往比单条SORTHEAP更值得调整。SHEAPTHRES是软限制，超过后新排序会直接使用临时空间而不等待内存排序堆。如果这个值设得太小，临时空间压力会显著上升。后续章节展开参数组合调整。

4. 解决问题的三套组合拳：扩容、回收、改语句

4.1 先扩容：临时空间不够时最快的止血方式

问题定位之后，第一优先是恢复业务，保证SQL能跑完。扩容是所有方案里执行最快、风险最低的一个。DB2的表空间扩容可以通过ALTER TABLESPACE增加容器大小，或添加新容器：

db2 connect to sample db2 alter tablespace TEMPSPACE1 resize (FILE '/db2/temp/ts1' 60000) db2 connect reset

RESIZE的60000单位是页，需要结合页大小换算。常见的8KB页大小，60000页约490MB。这里调整的是容器最大尺寸，相当于一种预防手段，不能解决“SQL本身要写更多数据到临时空间”的根本问题。如果文件系统空间充足，可以先扩容让跑批恢复；如果盘本身紧张，则需要先清理再考虑扩容。

扩容操作本身不会中断现有SQL运行，但在高并发状态下alter tablespace会有短暂的元数据锁等待。大促期间执行前看一眼活动会话数，太多活动会话时建议把alter放到窗口期执行。

另一个方式是ADD多个容器均匀分布IO：

db2 alter tablespace TEMPSPACE1 add (FILE '/db2/temp/ts2' 30000)

这段话的含义是在原有容器基础上增加一个文件容器，DB2会自动将新临时页分布到新容器上。物理上分散IO对大批量排序有实际收益，但要注意所有容器必须分布在不同的物理磁盘或使用条带化存储。如果把两个容器放到同一块盘上，分散IO只是心理安慰，实际热点的存在会让效果打折扣。

扩容后的观察不能只看表空间总量，还要看新容器上的页数分布。db2pd -tablespaces输出的容器信息里，每个容器都有独立的页数。如果新容器的使用率很快顶满而老容器一直闲置，说明数据存在倾斜，这时要检查是否有多温度存储的配置在起作用。

4.2 再改参数：SORTHEAP、SHEAPTHRES以及哈希堆的配合调整

扩容只是保命，真正消除临时表空间压力要靠参数调整。SORTHEAP控制单条语句的排序堆大小，SHEAPTHRES控制所有排序堆的总量。这两个值过小，排序操作频繁溢出到临时表空间；过大，内存可能被排序吃光，引发内存换页，甚至导致实例崩溃。调参追求的是“排序尽量在内存完成，又不挤出其他缓冲池”。

一个可行的调整路径：

db2 update db cfg for sample using SORTHEAP AUTOMATIC db2 update db cfg for sample using SHEAPTHRES 0 db2 update db cfg for sample using SHEAPTHRES_SHR 40000

AUTOMATIC表示排序堆由优化器根据当前可用内存自动伸缩，SHEAPTHRES设为0表示不设硬性上限，SHEAPTHRES_SHR则是共享排序的阈值。这套配置适合专用数据库服务器、内存充足的场景。第一行语句让单条排序尽量用内存，第二行放开总量限制，第三行为共享排序设置一个保护阀值。

这里必须强调，SHEAPTHRES设为0不等于没有上限——数据库自己会估算可用内存，但如果不限制实例中所有排序堆总和，多个并发排序仍可能把内存吃满。生产环境建议保留一个非0值的SHEAPTHRES，实际值根据业务并发和物理内存测算。常见做法是设为SORTHEAP乘以预期最大并发排序数的一半。

哈希连接同理，DB2没有专门的哈希堆参数，他复用排序堆机制。如果EXPLAIN计划里HSJOIN成为主要临时空间消耗点，优化方向不是调参而是改SQL——大表连接的ON条件加上过滤谓词，减少参与哈希的中间结果集。哈希连接写临时空间的本质是中间结果集过大，排序堆再大也有限度。

对SHEAPTHRES_SHR的调整，有一个用户容易踩的坑：调整后共享排序排序堆变大，但私有排序堆不受SHEAPTHRES限制，结果临时空间没有缓解。判断实际生效的参数需要看数据库快照里Shared Sort Heap Allocated和Private Sort Heap Allocated两个字段的大小关系。不急，下一节专门讲参数验证。

4.3 加workload管理：给临时表空间使用量设硬上限

参数调整后再加一道保险：用WORKLOAD MANAGEMENT限制单条SQL的临时表空间使用。DB2的workload manager可以把活动和临时表空间用量挂钩，超过阈值自动报错或降级。这条防线用于防止未来再次出现一条SQL吃爆整个临时表空间。

创建workload的示例：

CREATE WORKLOAD WL_TEMP_LIMIT APPLNAME('BATCH*') CURRENT TEMPSPACE USAGE 8000;

这段SQL限制APPLNAME以BATCH开头的应用临时空间使用量不超过8000页（8KB页约64MB）。超过时DB2会中止语句并报告资源限制。这个动作可能让业务SQL报错失败，但比拖垮整个数据库要好。具体阈值需要先测量正常业务的使用量，再在其上方留30%余量。

用WORKLOAD的限制比单纯靠SORTHEAP更可控，因为SORTHEAP只影响排序路径，而临时表空间还可能被物化表、哈希连接、OLAP函数占用。WORKLOAD的CURRENT TEMPSPACE USAGE是综合性限制，阻止任何形式的临时空间滥用。

较为精细的阈值可以按照查询类别分开设置——报表类限制800MB，OLTP类限制200MB，后台批处理类限制2GB。这样设置的核心原因是不同类别的SQL对临时空间的正常需求差距很大，一刀切800MB可能导致批处理全部失败，而设2GB又无法约束OLTP的异常查询。分层限制会根据实际情况把异常隔离在单一业务范围内，防止互相拖累。

4.4 检查连接池和应用侧并发：别让低效SQL叠加

参数和workload都设置好之后，还有一个经常被忽略的位置：应用侧的并发控制。数据库能同时打开的排序堆和临时表空间不像物理资源一样能排队，如果几十个恶意查询同时进来，每个都分配几MB临时空间，总量同样飙升。

在应用侧对执行耗时长的SQL做数据库端的查询治理是个有效方案——DB2的query governor可以根据估计成本限制SQL执行。配置方法：

db2 update db cfg for sample using DFT_QUERYIO_SORT YES

这个参数控制是否允许排序操作将中间结果写入临时表空间。类似参数还有MAX_QUERY_COST，设一个估计成本上限，超出的SQL直接被拒绝执行，不给它分配临时表空间的机会。该参数只适合在业务稳定、SQL模式固定的环境配置，新业务上线时容易误杀。

从源头控制并发更实用的做法是调节连接池的maxPoolSize，或者检查应用是否在循环中调用同一个低效查询。排查时观察活动连接数，如果不过关可以先按连接池优化的角度处理：

db2 get snapshot for db on sample | grep -E "Applications connected currently|High water mark"

Applications connected currently是当前应用连接数，High water mark是高峰值。连接数比业务高峰预期多出几倍时，可以怀疑是应用连接泄漏或并发超发。减少连接本身并不减少SQL的临时空间消耗，但能减少同时进行的排序数量，让SHEAPTHRES的限额更可控。

5. 避坑与常见问题：DB2临时表空间运维的5个典型坑

5.1 直接DROP重建系统临时表空间

现象：觉得临时表空间碎片化严重，直接DROP掉TEMPSPACE1再重建，认为这样最干净。

原因：系统临时表空间是数据库实例初始化时的核心资源，Dropping不会失败，但重建后需要重新对临时表空间授权、确认页大小与缓冲池匹配。更重要的是，在部分DB2版本中，DROP系统临时表空间后，正在使用该表空间的活动语句会收到SQL1477或直接回滚。生产环境有跑批任务时这样操作，后果往往是任务中断。

解决：系统临时表空间不需要“碎片整理”，页是按需分配的，DBA只要关注使用率。要大动干戈时先确认无活动语句，再重建临时表空间，否则用ALTER TABLESPACE RESIZE扩容量即可。重建本身不能恢复性能，它只能重置高水位。实际收益微乎其微，风险却很大。

5.2 把PAGESIZE调大就能一劳永逸

现象：临时表空间频繁打满，DBA认为把页大小从8KB改成32KB，单页能装更多行，表空间能容纳更多数据。

原因：页大小影响的是单页面内能存储的最大行宽，不影响排序的物理数据量。一条SQL要排100万行，8KB页需要约5000页，32KB页也差不了多少。真正决定临时空间占用的是记录行数和每行平均宽度，不是页大小。

解决：调大页大小只对行宽超过页限制的场景有意义，对临时表空间打满问题基本无效。排查重点应放在SQL的中间结果集大小和排序溢出情况上，而不是调整页大小。

5.3 把SORTHEAP调小反而更快

现象：为了减少内存占用，DBA把SORTHEAP从512页调小到128页，结果临时表空间打满的频率反而更高了。

原因：SORTHEAP越小，排序越容易溢出到临时表空间。溢出后DB2要把排序段写入临时文件再分段读取，IO开销远高于内存排序。这个设定看似省了内存，实则把压力转移到了IO路径。

解决：调小SORTHEAP前先看SORT_OVERFLOWS。溢出不明显的情况下调小SORTHEAP可能是合理的，大量溢出时调小SORTHEAP就属于反向操作。调整时配合监控验证：SORT_OVERFLOWS上升就调回去，没有明显变化再调整其他参数。

5.4 只盯系统临时表空间，忽略用户临时表空间

现象：系统临时表空间水位正常，但数据库性能依然差，排查后才发现是用户临时表空间几乎被占满。

原因：应用显式使用DECLARE GLOBAL TEMPORARY TABLE创建临时表时，数据落在用户临时表空间。该表空间不在系统临时空间的监控范围内，但容量不足时同样会引发SQL失败。排查临时空间问题时，只扫描系统临时表空间容易漏掉这一块。

解决：巡检时同时看SYSCAT.TABLESPACES中TYPE为'T'的所有记录，包括系统临时和用户临时两类。用户临时表空间增长速度更依赖具体应用，容量规划时按应用临时表的需求单独评估。

5.5 云数据库上临时空间慢，但磁盘监控里看不到

现象：云上的DB2实例临时表空间用量不大，但排序类SQL总是慢，云厂商控制台显示磁盘使用率不到30%。

原因：云数据库的临时空间通常落在实例本地的临时盘上，与持久化数据盘分离。控制台的磁盘使用率指标可能只反映数据盘，不反映临时盘。如果临时盘使用的是普通云硬盘且规格不高，IOPS和带宽都有限，排序SQL的吞吐会被限制，但监控面板上不会显示为“磁盘满”。

解决：使用云数据库时，先确认临时表空间所在的物理介质和规格。如果有云监控的实例级IO指标，对比排序时段与IO指标的曲线是否同步。瓶颈在IO的典型表现是：CPU不高、内存不高、临时表空间用量不高，但排序SQL的执行时间是常规时段的数倍。

6. 把临时表空间监控做成日常巡检的一部分

先给出一个最小监控SQL，每日巡检一次，基本能覆盖临时表空间的大部分异常：

SELECT TABSPACE, PAGESIZE, TOTAL_PAGES * PAGESIZE / 1024 / 1024 AS TOTAL_MB, USED_PAGES * PAGESIZE / 1024 / 1024 AS USED_MB, DECIMAL(USED_PAGES * 100.0 / TOTAL_PAGES, 5, 2) AS USED_PCT FROM SYSCAT.TABLESPACES WHERE TBSPACE TYPE = 'T' AND USED_PAGES > 0;

这段SQL输出所有临时表空间的总量、用量和百分比。判断标准：USED_PCT超过70%持续小时级别时，说明有问题；超过90%时，如果没有workload管理兜底，数据库随时可能报SQL0964C。巡检时把这3个字段的历史曲线存下来，出现性能问题时可以立即对比当前值和峰值。

我习惯的做法是把这条SQL配到定时任务里，每天早上8点跑一次，输出追加到文件，再配一个简单的阈值告警。有人觉得这小题大做——但临时表空间的问题大多不是瞬间爆炸，而是持续水位抬高后，某条SQL成为压死骆驼的最后一根稻草。有了每日水位记录，排查时能直接回答“为什么昨天还好今天就不行”，而不是靠猜。

针对报表类和批处理类业务，还有两个更细的预防手段。一个是给报表SQL做离线explain检查，依赖分析临时表空间的关键节点：SORT、HSJOIN、TBSCAN with SORT。另一个是在上线前跑一次全量测试，记录每条新SQL的TEMP_TABLESPACE_TOP，超出基线的直接在测试阶段优化，而不是等生产环境突然变慢再去抓。

给项目做定期巡检时，我还会在每周报告里附一张临时表空间趋势表：峰值时段、峰值用量、对应SQL文本片段。这张表积累三个月后，不仅能看出容量增长趋势，还能反向推出业务侧的哪些新功能在增加排序量。曾经的某客户，报表系统每月临时空间用量翻倍，最后定位到某张宽表新增了几个字段，所有COUNT DISTINCT查询的计算量成倍增长。如果不是有每周的趋势数据，这个问题很可能要到永久表空间耗尽才会被发现。

临时表空间的问题，本质是SQL效率问题的投影。把监控做成习惯，把优化做成流程，远比某一次“救火”更有价值。每次处理完这类问题，我都会把抓到的SQL文本、当时的参数组合、调整前后的数据存成一份记录，下次遇到类似问题先翻记录，而不是重新排查一遍。希望这些经验能帮你少走一些弯路。

本文还有配套的精品资源，点击获取