The optimizer might favour a hash join (HSJOIN) over a nested
loop join (NLJOIN) alternative under the following conditions:
- the join is on two or more columns
- both tables in the join have an index with leading, non-bound
key columns that participate in the join
- one or more leading columns match in order of the join
columns, but not all
For example, consider the following query
SELECT *
FROM T1,T2
WHERE T1.A=T2.A and T1.B=T2.B and T1.C=T2.C and T1.X=1;
where index IX1 is defined on T1(X,A,C,B) and index IX2 is
defined on T2(A,B,C). The column T1.X is bound to the constant
1 as a result of the predicate "T1.X=1" so for the NLJOIN with
IX1 access on the outer and IX2 access on the inner, the leading
non-bound columns for both indexes are referenced in the join
predicate T1.A=T2.A, but the subsequent columns are not ordered
in join column order. Under these conditions, the optimizer
might over estimate the cost of the NLJOIN alternative,
favouring a possibly worse-performing HSJOIN alternative |
Create an index on either table, ensuring that the key columns
are in join order. Referring to the example in the Error
Description, this could be achieved by creating an index on
T2(A,C,B). |
