Q表空间容量快满时，通常会出现哪些预警信号？当表空间接近上限时，常见表现包括写入变慢、批量导入失败、业务报错提示无法分配空间，以及监控平台出现使用率告警。你也可以通过查询数据文件剩余空间、段增长情况和历史峰值，提前判断风险。
A先识别风险信号，再判断是临时波动还是持续增长
可以结合监控告警、业务报错和空间查询结果一起判断。如果只是短时间占满，可能是批处理或大事务引起；如果增长持续存在，说明需要尽快扩容、清理无用数据或调整对象存储策略。
Q扩容表空间时，应该优先加数据文件还是调整自动扩展？很多人遇到空间不足时会直接加大容量，但不同场景的处理方式并不一样。是手动新增数据文件更合适，还是开启自动扩展更稳妥，需要结合磁盘剩余、表空间类型和运维规范来判断。
A根据业务稳定性和磁盘余量来选择扩容方式
如果磁盘空间充足且希望快速缓解压力，可以增加数据文件或放大现有文件。若业务增长较稳定，开启自动扩展能减少频繁人工操作。对于核心生产库，建议设置合理上限，避免自动扩展把磁盘占满。
Q表空间不足时，清理哪些内容更安全有效？不是所有空间都能通过删除数据立即释放，有些对象删除后也未必马上回收。实际处理时，哪些历史表、索引、临时对象或日志类数据更适合优先处理，才不会影响线上业务？
A优先清理可确认无业务依赖的历史数据和临时对象
可以先排查过期归档表、测试数据、临时表和无效索引，再评估是否能压缩表或重建索引。对业务表做删除前，建议确认是否存在报表、接口或定时任务依赖，避免误删影响生产。
Q如果临时表空间报警，处理方式和普通表空间一样吗？临时表空间满了之后，排序、哈希连接和大查询可能会受影响，但它和普通业务表空间的处理思路并不完全相同。遇到这种情况，应该先排查查询还是直接扩容？
A先定位占用临时空间的SQL，再决定扩容还是优化
临时表空间不足时，建议先查看是否有大排序、大聚合或异常SQL占用资源。若是单条SQL导致的峰值，优化语句或拆分任务更有效；若是并发高峰造成的普遍压力，可以适当增加临时表空间大小，并配合SQL治理降低重复消耗。