仅靠表空间物理分离无法实现冷热数据查询隔离，因oracle优化器不识别表空间名，分区裁剪依赖where中的分区键值；必须选用createdtime作range分区键并强制应用层带该条件查询。
直接用表空间隔离冷热数据是可行的，但必须配合分区策略和访问控制，否则查询时仍会扫描全部分区，起不到性能优化作用。
为什么不能只靠表空间物理分离
Oracle 表空间只是逻辑容器，不参与 SQL 执行计划生成。即使把旧分区挪到 TS_COLD、新分区留在 TS_HOT，只要查询没带上分区键条件，优化器仍可能全表扫描所有分区——冷热物理分离 ≠ 查询逻辑隔离。
- 分区裁剪（Partition Pruning）依赖
WHERE中的分区键值，不是表空间名 -
ALTER TABLE ... MOVE PARTITION ... TABLESPACE TS_COLD只改存储位置，不改元数据中的分区逻辑关系 - 若业务查询长期不带分区字段（如只查
assignedUserID），分区本身已失效，表空间再分也没意义
必须先选对分区键，否则表空间分级就是摆设
从你提供的工单场景看，createdTime 是唯一符合分区裁剪要求的字段：它天然有序、高频用于时间范围查询（如“近7天”“上月”），且与冷热定义强相关（关闭超30天即为冷数据）。
- 用
RANGE(createdTime)分区，比如按月：PARTITION p_202604 VALUES LESS THAN (TO_DATE('2026-05-01','YYYY-MM-DD')) - 主键需包含
createdTime→ 改为复合主键(ticketID, createdTime)，否则建分区表会报错ORA-14038 - 禁止用
assignedUserID或consumerEmail做分区键——它们无法支撑“冷数据归档”动作，也难保证裁剪效果
表空间分级的关键操作步骤
确认分区键后，表空间分级才真正生效。核心是让冷分区不可写、热分区可写，并在应用层强制走分区键查询。
- 创建专用表空间：
CREATE TABLESPACE ts_hot DATAFILE '/u01/oradata/hot01.dbf' SIZE 10G;，CREATE TABLESPACE ts_cold DATAFILE '/u02/oradata/cold01.dbf' SIZE 50G; - 移动旧分区到冷表空间：
ALTER TABLE ticket_tab MOVE PARTITION p_202603 TABLESPACE ts_cold; - 设冷分区为只读：
ALTER TABLE ticket_tab MODIFY PARTITION p_202603 READ ONLY;（防止误更新，也向优化器传递“此分区无新数据”信号） - 定期归档脚本示例（每月1日执行）：
ALTER TABLE ticket_tab EXCHANGE PARTITION p_202603 WITH TABLE ticket_arch_202603 INCLUDING INDEXES;
再把ticket_arch_202603表迁至压缩表空间或导出为 dump
最容易被忽略的坑：应用层没适配分区键
即便分区和表空间都配好了，如果客服系统发来的 SQL 是 SELECT * FROM ticket_tab WHERE assignedUserID = 123，Oracle 仍会扫描所有分区——因为没提供 createdTime 条件，分区裁剪完全失效。
- 必须改造应用：所有查询强制加时间范围，例如
AND createdTime >= TRUNC(SYSDATE) - 30 - 对历史查询需求（如组长查“全组近半年工单”），用物化视图或后台异步聚合表替代实时扫描
- 监控
V$SQL_PLAN中PARTITION_START/PARTITION_STOP是否为具体分区号，而非KEY或ALL
