分区本身不加速查询，只在配合正确谓词和执行计划时才生效；盲目分区甚至拖慢小范围查询，因无分区键条件时会触发全分区扫描，元数据开销更大，且需检查执行计划是否出现PARTITION RANGE ALL等未裁剪信号。
直接上结论：分区本身不加速查询，只在配合正确谓词和执行计划时才生效；盲目分区甚至会拖慢小范围查询。
为什么加了分区，SELECT COUNT(*) 还是慢？
分区不是索引，它只是物理数据的组织方式。如果查询没带分区键条件（比如没写 WHERE create_date >= '2025-01-01'），Oracle 仍需扫描所有分区——这叫“全分区扫描”，比普通表还多一层元数据开销。
- 检查执行计划是否出现
PARTITION RANGE ALL或PARTITION LIST ALL，这是典型未裁剪信号 -
INTERVAL分区表首次访问新时间范围时，会触发隐式分区创建，可能卡在 DDL 锁上 - 分区列类型和查询条件类型不一致（如分区列是
DATE，但条件用了字符串'2025-01-01'），导致无法做分区裁剪
DBA_TAB_PARTITIONS 和 USER_TAB_PARTITIONS 查不到分区信息？
常见原因不是没分区，而是权限或对象归属问题：
- 用
SELECT * FROM USER_TAB_PARTITIONS WHERE table_name = 'LOT_MASTER'前，先确认当前用户确实是该表 owner；否则查ALL_TAB_PARTITIONS，并注意table_owner字段 - 分区表若建在其他 schema（如
RPTDW），而你当前连的是SCOTT，USER_*视图必然为空 - 对象名大小写敏感：建表时用了双引号（如
"Lot_Master"），查询时必须严格匹配大小写
滚动窗口场景下，DROP PARTITION 为何卡住？
删除分区本质是 DDL 操作，会持锁并阻塞并发 DML。尤其在 OLTP 侧仍有写入时：
- 避免在业务高峰执行
ALTER TABLE ... DROP PARTITION；改用EXCHANGE PARTITION先切出旧分区到临时表，再异步清空 - Oracle 12c+ 支持
ONLINE选项（ALTER TABLE ... DROP PARTITION ... UPDATE INDEXES ONLINE），但前提是索引已建为LOCAL - 若分区含大量 LOB 数据，
DROP会触发段清理，可提前用ALTER TABLE ... MODIFY PARTITION ... SHRINK SPACE预回收
分区键选 create_date 还是 lastlogin？
关键看查询模式，不是看字段名里有没有“时间”：
- 如果 90% 查询都带
WHERE create_date BETWEEN ...，且该列更新极少，就选它——稳定性压倒一切 - 若
lastlogin频繁更新（如每小时刷新一次），会导致大量跨分区行迁移（ROW MOVEMENT开启后），严重拖慢 DML 性能 - 复合分区（如
RANGE-LIST）适合多维过滤场景，但维护成本翻倍；别为了“看起来高级”而用
最常被忽略的一点：分区裁剪（partition pruning）是否真正生效，不能只看执行计划里有没有 PARTITION RANGE SINGLE，还得核对 START/STOP 的实际分区名——有时计划显示裁剪了，但因绑定变量窥探失败，运行时仍扫了 12 个分区。
