我想为Oracle应用程序表创建以下索引。
create index xxhr_api_transactions_idx1 on hr.hr_api_transactions (status, process_name, nvl(selected_person_id, -1)) compress 3
该表总共有62421行。状态列中的10个不同值。 process_name
列中有23个不同的值。 selected_person_id
列中有17419个不同的值。 selected_person_id
列仅存在43530个值,其余值为空(新员工工作流程尚未存在)。
我的查询类似于:
select *
from hr.hr_api_transactions psth
where psth.process_name in ('TFG_HR_NEW_HIRE_PLACE_JSP_PRC', 'HR_NEW_HIRE_PLACE_JSP_PRC', 'HR_NEWHIRE_JSP_PRC') -- TFG specific.
--and nvl(psth.selected_person_id, -1) in (:p_person_id, -1) -- 1118634
and psth.status not in ('W', 'S') -- Work in Progress, Saved For Later.
我的问题是我应该使用压缩3还是压缩2?是否更好地压缩selected_person_id
列中的17419个不同值,总共62421个(以及18891个空值)或不是?
答案 0 :(得分:1)
压缩声明和建议非常糟糕。这是您真正需要自己测试的任务之一。您可以通过选中DBA_SEGMENTS.BYTES
。
压缩是CPU和大小之间的权衡。根据我的经验,基本索引压缩的CPU开销非常小。只要尺寸小于百分之几,我就建议使用增加的压缩设置。
使用以下代码测试最高为compress 3
的无压缩段大小。确保使用足够大量的数据进行测试。 Oracle在范围内分配空间;如果你使用一个小的测试大小,你只会测量范围大小开销。
drop index hr.xxhr_api_transactions_idx1;
create index xxhr_api_transactions_idx1 on hr.hr_api_transactions (status, process_name, nvl(selected_person_id, -1));
select bytes/1024/1024/1024 gb from dba_segments where segment_name = 'XXHR_API_TRANSACTIONS_IDX1';
drop index hr.xxhr_api_transactions_idx1;
create index xxhr_api_transactions_idx1 on hr.hr_api_transactions (status, process_name, nvl(selected_person_id, -1)) compress 1;
select bytes/1024/1024/1024 gb from dba_segments where segment_name = 'XXHR_API_TRANSACTIONS_IDX1';
drop index hr.xxhr_api_transactions_idx1;
create index xxhr_api_transactions_idx1 on hr.hr_api_transactions (status, process_name, nvl(selected_person_id, -1)) compress 2;
select bytes/1024/1024/1024 gb from dba_segments where segment_name = 'XXHR_API_TRANSACTIONS_IDX1';
drop index hr.xxhr_api_transactions_idx1;
create index xxhr_api_transactions_idx1 on hr.hr_api_transactions (status, process_name, nvl(selected_person_id, -1)) compress 3;
select bytes/1024/1024/1024 gb from dba_segments where segment_name = 'XXHR_API_TRANSACTIONS_IDX1';