索引扫描变慢主因是索引段与表段共存同一数据文件引发I/O争用，需手动将索引重建至专用表空间的独立数据文件，并设置UNIFORM SIZE确保extent连续，避免碎片化随机I/O。
为什么索引扫描变慢？先确认是不是段位置导致的I/O争用
索引扫描性能下降，不一定是sql写得差或缺少索引，很可能是索引段和其对应表段混在同一个数据文件里，造成物理读竞争。尤其当表频繁dml、索引又高并发查询时，db file sequential read等待会明显上升。oracle不会自动把索引“挪开”，必须手动干预段存放位置。
如何把索引移到专用的数据文件（非SYSTEM/USERS表空间）
核心是让索引段脱离原表所在的数据文件，放到I/O压力小、条带更优的独立文件中。不能只靠ALTER INDEX ... REBUILD加TABLESPACE子句——那只是换表空间，如果目标表空间里多个数据文件混用，效果有限。
- 先创建专用索引表空间，指定单个大文件（避免多文件引入LMT管理开销）：
CREATE TABLESPACE idx_tbs DATAFILE '/u01/oradata/db/idx01.dbf' SIZE 2G AUTOEXTEND ON NEXT 100M;
- 重建索引时强制指定数据文件路径（需DBA权限且数据库为ARCHIVELOG模式）：
idx_order_status
- 验证是否真正分离：查
dba_extents，确认索引段的file_id和原表段的file_id不同：SELECT segment_name, file_id, block_id FROM dba_extents WHERE segment_name IN ('ORDERS', 'IDX_ORDER_STATUS');
REBUILD ONLINE和MOVE的区别：别误用MOVE来“挪”索引
ALTER INDEX ... MOVE是非法语法——索引不支持MOVE，只有表才支持。常见错误是把表的优化习惯套到索引上，结果报错ORA-02149: Invalid partition name或直接语法失败。唯一合法的物理重定位方式就是REBUILD。
-
REBUILD ONLINE允许DML并发，但会短暂持有SR（Share Row）锁，不影响SELECT - 若业务能接受短暂停写，用
NOLOGGING可提速3–5倍（尤其大索引），但归档日志不记录块变更，恢复窗口内重建失败需重做 - 重建后记得收集统计信息：
SCOTT
容易被忽略的底层细节：Extent大小与存储参数对扫描效率的影响
即使挪到了新文件，如果索引段的INITIAL和NEXT太小（比如默认64K），会导致extent碎片化，一次索引范围扫描可能触发数十次随机I/O。这不是缓存问题，是物理布局缺陷。
- 重建时显式指定大extent：
idx_order_status
- 检查当前索引的存储参数：
IDX_ORDER_STATUS
- 注意：
ASSM（自动段空间管理）表空间下INITIAL/NEXT会被忽略，此时应确保表空间使用UNIFORM SIZE，例如：CREATE TABLESPACE idx_tbs DATAFILE '/u01/.../idx01.dbf' SIZE 2G EXTENT MANAGEMENT LOCAL UNIFORM SIZE 1M;
真正起效的是数据文件的物理分布+extent连续性，不是表空间名字有多“专用”。很多DBA改了表空间名却没调uniform size，结果I/O还是散的。
