SYSTEM分区表需显式指定分区名插入，不支持分区裁剪与本地索引，适用于多租户强隔离等业务完全掌控路由的场景。
SYSTEM 分区表在 Oracle 中是一个特殊且小众的类型，它不依赖分区键自动路由数据，而是由应用显式指定插入到哪个分区。它解决的不是“怎么分”，而是“我明确要往哪放”。
SYSTEM 分区表适合那些数据路由逻辑完全由业务控制、无法用常规字段建模、且需要强隔离与独立管理的场景。
SYSTEM 分区表只适用于明确指定分区名的 INSERT 场景
- 插入语句必须带
PARTITION (partition_name)子句，否则报错ORA-14702: partition name must be specified for system partitioned table - 不能用
INSERT ... SELECT不带分区名的方式批量导入；也不能用普通INSERT INTO table VALUES (...) - 所有 DML（包括
UPDATE、DELETE）也必须显式指定分区，否则报错 - 查询时若不加
PARTITION提示，会扫描所有分区（无分区裁剪），性能反而更差
这意味着：它天然不适合时间序列、地区分类、ID哈希等可推导路由的常规业务，只适合“我清楚知道这条记录该进哪个桶”的强管控流程。
常见适用场景：多租户混存 + 租户级独立生命周期
- 多个客户/租户共用一张日志或事件表，但每个租户的数据必须物理隔离（合规要求）、备份恢复独立、归档策略不同
- 租户 ID 不是表中字段（或不能作为分区键，比如租户标识是外部令牌、UUID、或加密值，无法用于范围/列表/哈希分区）
- 应用层已做路由决策，例如：收到 Webhook 后解析 header 中的
X-Tenant-ID，再决定插入PARTITION p_tenant_abc123
这时 SYSTEM 分区比用 LIST 或 HASH 更干净：不用在表里冗余存租户字段，也不用担心哈希冲突或列表枚举漏项。
容易踩的坑：索引、统计信息和运维盲区
-
SYSTEM分区表不支持本地索引（LOCAL index），只能建全局索引（GLOBAL）——意味着索引维护成本高，且无法按分区重建 -
DBMS_STATS收集统计信息时，默认不收集分区级统计，需手动指定granularity => 'PARTITION'，否则优化器可能误判执行计划 -
ALTER TABLE ... DROP PARTITION语法不支持，只能用TRUNCATE PARTITION或DROP TABLE PARTITION（后者需先清空） - 没有
USER_TAB_PARTITIONS视图里的HIGH_VALUE字段（因为没分区键），排查数据分布只能靠COUNT(*) GROUP BY PARTITION_NAME
这些限制让 SYSTEM 分区表一旦用错，后期很难收场。它不是“更灵活的分区”，而是“把分区控制权彻底交给应用”的契约型设计。
真正要用 SYSTEM 分区，说明你已经放弃了让数据库理解业务语义，转而自己扛起数据路由、生命周期、一致性校验的全部责任。这种选择，往往出现在租户隔离等级极高、或遗留系统改造受限的边界场景里。
