普通用户需显式授予create any index系统权限才能建索引，resource角色不包含该权限，dba角色虽含此权限但不应滥用；限制仅对自己表建索引应授alter权限或自定义角色。
直接授予 create any index 权限才能建索引
oracle 中，普通用户默认没有创建索引的权限，即使已拥有 create table 或 resource 角色也不行。必须显式授予系统权限 create any index，否则执行 create index 时会报错：ora-01031: insufficient privileges。
-
create any index是系统权限（system privilege），不是对象权限，不依赖具体表归属 - 授予该权限后，用户可在任意 schema 的表上建索引（包括其他用户的表），不限于自己创建的表
- 若只想让用户在自己拥有的表上建索引，应避免用
create any index，改用角色或细粒度控制（见下一条）
resource 角色不包含建索引权限
很多人误以为 resource 角色能覆盖所有 DDL 操作，但 Oracle 官方定义中，resource 只含 create cluster、create procedure、create sequence 等权限，明确不含 create index —— 这是设计上的刻意分离。
- 验证方式：登录目标用户后执行
select * from session_privs;，查不到CREATE ANY INDEX - 执行
grant resource to user_a;后仍无法建索引，必须额外补授create any index - DBA 角色虽包含该权限，但不应为普通用户直接授予
dba，权限过大且违反最小权限原则
限制用户只能在自己表上建索引的替代方案
如果业务要求更严格（比如开发人员只能给自己表加索引），不能直接给 create any index，需组合使用对象权限与自定义角色：
- 先确保用户对自己表有
ALTER权限（建索引本质是修改表结构）：grant alter on schema.table_name to user_a; - 或创建专用角色：
create role idx_dev_role;→grant alter any table to idx_dev_role;→ 再只把该角色授给可信用户 - 注意：
alter any table权限比create any index更宽（可改表结构、重命名、加列等），需评估风险 - 没有“仅允许建索引但不可改表”的原生权限粒度，这是 Oracle 的权限模型限制
撤销索引权限时 cascade 不生效
用 revoke create any index from user_a; 可立即生效，但已存在的索引不会被自动删除——Oracle 不支持权限回收触发对象级级联清理。
- 用户仍可正常使用已有索引，查询计划不受影响
- 若需彻底清理，得手动执行
DROP INDEX owner.index_name; - 回收权限后，该用户再尝试建新索引会立刻报
ORA-01031，无静默失败 - 别指望
drop user ... cascade帮你删索引以外的对象；它只删用户 owns 的对象，不删别人表上的索引（哪怕是他建的）
实际中最容易忽略的是：建索引权限和“能否访问目标表”是两回事。即使有 create any index，若对某张表没有 SELECT 权限，CREATE INDEX 仍可能失败（尤其涉及函数索引或基于表达式的索引）。得确认底层表访问权限也到位。
