assm是oracle 9i起默认的自动段空间管理机制，用位图替代freelist实现并行空间分配，显著降低buffer busy wait、提升并发dml性能，并自动减少碎片、免调pctused等参数。
绝大多数情况下，选 ASSM —— 不是“推荐”，而是 Oracle 自 9i 起的默认且事实标准；只有极少数遗留场景才需考虑 MSSM。
ASSM 是什么，为什么它几乎总是更优
ASSM（Automatic Segment Space Management）用位图块（L1/L2/L3）替代 freelist，把“找空闲块”这个动作从串行排队变成并行扫描。真实业务中，只要表有并发 INSERT（比如订单、日志、计数器类表），MSSM 很快就会出现 buffer busy wait 和 read by other session 等等待事件——因为所有会话都在争抢同一个 freelist 链（尤其 FREELISTS=1 时）。ASSM 下这些等待基本消失，50 并发 INSERT 场景下响应时间通常低 30%~60%。
ASSM 还带来两个隐性好处：
– 位图自动合并碎片，减少行迁移风险（但不消除）
– 不依赖 PCTUSED 或 FREELISTS，DBA 不用反复调参
– 在 RAC 环境中，位图能动态亲和不同实例，避免跨节点争用
MSSM 仅在哪些具体场景下仍可考虑
MSSM（Manual Segment Space Management）不是“过时”，而是适用面极窄。目前仅以下情况可能需要保留或显式选用：
- 正在维护一个运行十年以上、从未重建的 OLAP 历史归档库，且已确认其核心大表（如分区表）在 MSSM 下长期稳定，无并发写压力
- 某些特殊中间件或旧版 ETL 工具硬编码依赖
FREELISTS或PCTUSED参数行为（极少见，应优先升级工具而非迁就） - SYSTEM、UNDO、TEMP 表空间——它们强制使用 MSSM，但这跟性能无关，只因这些对象本身不承受高并发 DML
注意：CREATE TABLESPACE ... SEGMENT SPACE MANAGEMENT MANUAL 在现代 Oracle 中已不被鼓励，且无法用于本地管理表空间以外的类型（而字典管理表空间早已弃用）。
怎么确认当前表空间用的是 ASSM 还是 MSSM
别查表、别查段，直接查表空间级元数据：
SELECT tablespace_name, extent_management, segment_space_management FROM dba_tablespaces WHERE tablespace_name = 'USERS';
结果中 segment_space_management 列值为 AUTO 即 ASSM，MANUAL 即 MSSM。这是唯一可靠方式——dba_tables 和 dba_segments 里根本没有这个字段，查了也为空。
常见误判点：
– 看到 STORAGE (FREELISTS 5) 就以为是 MSSM？错。ASSM 表空间里这条语句不报错，但参数被 Oracle 静默忽略，dba_tables 中查不到对应值
– 查 PCTFREE 是否生效？它在两种模式下都有效，但作用不同：ASSM 中只控制 UPDATE 空间预留，不决定 INSERT 能否发生；MSSM 中它和 PCTUSED 共同决定 freelist 的进出逻辑
ASSM 下必须注意的三个实际约束
ASSM 不是“设了就不用管”，它简化了参数，但引入了新的行为边界：
-
PCTFREE是唯一有效的空间参数，FREELISTS、FREELIST GROUPS、PCTUSED全部失效，且不会报错——静默丢弃 - 位图块本身虽分散设计，但在极端超高频小事务（如每秒万级单行 INSERT）下，L1 位图块仍可能成为热点（此时需结合
INITRANS调整 ITL 槽位，而非动空间参数） - ASSM 只支持本地管理表空间（
EXTENT MANAGEMENT LOCAL），如果你还在用字典管理表空间，先升级表空间类型，再谈 ASSM
真正容易被忽略的，是“ASSM 的位图机制让块空闲率低于 PCTFREE 仍可接受新行”这一行为——它提升了吞吐，但也意味着你不能再靠 PCTFREE 来粗略估算块内还能塞几行；如果业务对单块行数有强预期（比如某些批量导出逻辑），得实测验证，不能凭经验推断。
