-2

当我运行合并查询时，索引无法读取并且查询运行速度很慢，请告诉我。

stage_dim_accounts(rbc_code) 中的索引

map_rbc_etl(free_code_9) 中的索引

MERGE INTO stage_dim_accounts t 
USING map_rbc_etl s ON (t.rbc_code = s.free_code_9)
WHEN MATCHED THEN UPDATE 
SET t.indx_no= s.indx_no  
WHERE s.annexure= 'AXN-I' 
AND (.free_code_9 <> 'NA' AND s.free_code_9   <> '0') 
AND t.rbc_code <> 'NA'

提前致谢

4

2 回答 2

3

优化器足够聪明，知道您的索引是无用的。

如果该列中的大多数值是“0”或“NA”，则索引free_code可能很有用。由于您没有提供有关数据量或分布的任何信息，我们无法确定。但是您对 有其他限制条件 map_rbc_etl，因此无论如何数据库都需要访问该表。我的猜测是优化器选择在 map_rbc_etl 上使用全表扫描，因为这比大量索引读取要快。

这是因为索引读取是两个操作 - 读取索引，读取行。因此，只有当读取的行的百分比很小时，它才会派发股息。否则，读取所有行并将它们筛选到内存中会更有效。

这是调优的“秘密”：索引读取并不总是更快；全表扫描并不总是坏事。

类似的逻辑适用于阅读stage_dim_accounts. 索引列不太可能是选择性的。除非 ... 除非 中的行数 map_rbc_etl非常少并且仅​​匹配 stage_dim_accounts. 我之前对数据指标的评论再次适用。

于 2013-03-14T12:33:48.553 回答
0

indexes to use on map_rbc_etl( free_code_9, annexure) and on stage_dim_accounts(rbc_code);

now these may not be used for reasons in previous answer. Additional reasons an index may not be used are: 1. The optimizer decides it would be more efficient not to use index. 2. if column is on view and has function call on column. To use this use function based indexes. 3. you perform mathematical operation in query. Note you can look at explain plan and create index to match how it is loading the rows. 4. you concat columns together in where clause. Use function based index for overcoming this. 5. You do not include first column in concatenated index in where clause of your statement. Note that Oracle 9i or greater do skip scanning and can use the index. 6. You use or clause. In this case it is best to create one index for all but the or clause and one for each of the or values then it will use all indexes appropriately.

if you don't know how to use function based indexes an example for a to_upper() in where clause you would use the following

create indexName on tableName(to_upper(colname));

any oracle sql function (built in or user created) can be in the index.

于 2013-03-29T20:02:13.117 回答