uniform size能减少表空间碎片，因其强制所有区等长，避免小大区混杂导致的“夹心式”空闲区，确保段扩展时总能找到连续可用区。
为什么 uniform size 能减少表空间碎片
本地管理表空间（LMT）中，区（extent）分配方式直接决定碎片程度。使用 uniform 时，所有区强制等长，避免了小块区反复穿插在大块区之间的典型碎片形态。而 autoallocate 会按需分配 64K、1M、8M 等多级尺寸，长期增删后极易形成“夹心式”空闲区——即两个大空闲区之间卡着几个无法被新段复用的小碎片区。
关键点在于：Oracle 段扩展时，必须申请连续的空闲区。哪怕表空间总空闲量充足，只要没有单个 ≥ 请求尺寸的连续空闲区，就会报 ORA-01653 或 ORA-01654 错误——这正是碎片的实操后果。
创建 uniform 表空间的实操要点
必须显式指定 size，否则语句会失败：
CREATE TABLESPACE tbs_uniform DATAFILE '/u01/oradata/db/tbs_uniform01.dbf' SIZE 100M EXTENT MANAGEMENT LOCAL UNIFORM SIZE 1M;
-
UNIFORM SIZE后必须跟具体数值，单位支持K、M，不写单位默认为字节 - 尺寸建议取值：64K（小表/索引）、1M（通用）、8M（大分区表），避开 512K、256K 这类易被
autoallocate频繁生成的中间尺寸 - 一个表空间只能有一种
UNIFORM SIZE，不可混用；也不能和autoallocate共存 - 数据文件初始
SIZE建议 ≥ 3×UNIFORM SIZE，否则首次扩展就可能触发自动增长，破坏均匀性
uniform 和 autoallocate 在真实负载下的表现差异
某日志表持续写入+定期清理的场景下对比：
-
autoallocate表空间运行 3 个月后，DBA_EXTENTS中出现 47% 的区尺寸 ≤ 64K，但实际新插入段平均请求 256K–1M，导致 62% 的空闲区无法被利用 - 同规格
uniform size 1M表空间，空闲区全部为 1M 整数倍，新段申请成功率 99.8%，且dba_free_space中最大空闲块 = 总空闲量 - 注意：
uniform不解决段内碎片（即块内行迁移/链式行），只解决区级碎片；仍需配合ALTER TABLE ... SHRINK SPACE或合理PCTFREE控制
容易忽略的限制与风险
UNIFORM 是一把双刃剑，硬约束带来确定性，也带来灵活性缺失：
- 无法为小对象（如小索引）节省空间：即使只存几百字节，也要占用整个 1M 区
- 无法适应突发大写入：若业务突然插入超大 LOB，而
UNIFORM SIZE设为 1M，则需分配数百个连续区，IO 压力陡增 - 不能跨表空间统一管理：每个
uniform表空间独立设置尺寸，DBA 必须提前规划不同业务模块的区大小策略 - 重建已有表空间必须导出导入，
ALTER TABLESPACE ... CONVERT不支持从autoallocate切换到uniform
真正难的不是选 uniform 还是 autoallocate，而是预估未来 2 年内该表空间里最小段和最大段的典型尺寸分布——这决定了你设的 SIZE 是刚好够用，还是成了隐形瓶颈。
