UNIFORM SIZE不可修改，须建表空间时确定；128K～256K适合中小业务表（如用户资料、订单明细），单行数据量适中且增长平缓。
UNIFORM尺寸不能事后修改，建表空间时定死就生效了——选错值会导致后续大量小对象浪费空间，或大对象频繁申请新区拖慢插入性能。
UNIFORM size 该设多大？看对象预期大小和增长节奏
不是越大越好，也不是越小越省；关键看你要放进去的表/索引是否尺寸接近、增长是否平缓：
- 128K～256K：适合中小业务表（如用户资料、订单明细），单行
- 1M：通用折中值，兼容多数 OLTP 场景，
dba_extents中每个 extent 约 128 块（按默认 8KB block_size），平衡碎片与管理开销 - 4M～8M：适合大型历史归档表、分区表主段、物化视图日志，避免每万行就触发一次 extent 分配
- 不建议用 64K 或 16K：虽然能“更精细”分配，但
dba_extents行数暴增，查询空间使用情况变慢，且 Oracle 内部位图管理开销上升
建表空间时指定 UNIFORM，建表时的 STORAGE 参数全失效
这是最容易踩的坑：哪怕你在 CREATE TABLE 里写了 INITIAL 64K NEXT 128K，只要表空间是 UNIFORM SIZE 1M，这些参数统统被忽略——首个 extent 和后续所有 extent 都是 1M。
- 验证方式：
SELECT extent_id, bytes FROM dba_extents WHERE segment_name = 'T1'，结果里所有bytes必须完全一致 - 查表空间实际配置：
SELECT allocation_type, uniform_size FROM dba_tablespaces WHERE tablespace_name = 'YOUR_TS' - 如果看到
allocation_type = 'UNIFORM'但uniform_size是NULL，说明建的时候漏写SIZE，Oracle 会 fallback 到默认 1M（但不报错）
UNIFORM 和 AUTOALLOCATE 混用？不行，必须全局统一
一个表空间只能选一种 extent 管理方式：UNIFORM 或 AUTOALLOCATE（即 SYSTEM）。临时表空间强制 UNIFORM，永久表空间可选，但一旦选定就不能改。
-
AUTOALLOCATE下，Oracle 自动给小段分 64K、中段 1M、大段 64M —— 看似省心，但混合大小 extent 容易造成位图位浪费和局部碎片 -
UNIFORM的优势只有在段数量多、尺寸分布集中时才明显；如果表空间里既有 10 行的小配置表，又有上亿行的流水表，强行统一 4M 会让小表每个都占 4M，纯属浪费 - 真实建议：按业务域拆表空间，比如
APP_USER_TS（128K）、APP_LOG_TS（4M），而不是塞进一个“万能”表空间
查已建表空间的 UNIFORM 设置是否生效
别只信建库脚本，生产环境常有迁移或误操作。最可靠的方式是直接查数据字典 + 实际 extent 分布：
- 确认表空间类型：
SELECT extent_management, allocation_type, uniform_size FROM dba_tablespaces WHERE tablespace_name = 'TS_NAME' - 确认某张表实际占用：
SELECT extent_id, bytes, blocks FROM dba_extents WHERE segment_name = 'TBL' AND owner = 'OWNER' ORDER BY extent_id—— 所有bytes必须严格相等才算UNIFORM生效 - 注意：
uniform_size单位是字节，不是 KB；128K 要写成131072，但 DDL 中支持128K这种写法，SQL*Plus 和 SQL Developer 都认
真正麻烦的不是选数字，而是选完之后没人再回头看——等某天发现 dba_extents 里有 20 万个 1M extent 全属于同一张小表，或者归档表每次 INSERT 都卡在 extent 分配上，问题根源早就在建表空间那条 UNIFORM SIZE 语句里了。
