# Working with Indexes - Case Study - Cont'd

![`smart`](OptimizerHints02_en_001_20240207.png)

----------------------------------------------------
We executed an SQL query with an `Optimizer Hint` as follows:

```
SELECT /*+ use_index(T1, idx_col2) */ col5, col6 FROM T1 WHERE col2 = 5 AND col1 = 1000 ORDER BY col3 DESC LIMIT 1;
```

The hint `/*+ use_index(T1, idx_col2) */` instructs the optimizer to use the `idx_col2` index, thereby replacing the `IndexFullScan` operator with the `IndexRangeScan` operator. As a result, we found that both the estimated number of rows (`estRows`) and the actual number of rows scanned (`actRows`) are 1,000. Although the `estRows` value for the `IndexRangeScan` operator is higher than that of the `IndexFullScan` operator, prompting the optimizer to choose `IndexFullScan`, the `actRows` value for `IndexRangeScan` is lower. This indicates that the `Optimizer Hint` successfully optimizes this SQL query.

The calculation for the `estRows` value using the `IndexRangeScan` operator is: target number of rows x selectivity, which in this case is 100,000 x 1/100 = 1,000 rows. For the Selection operator below it, the calculation method is similar: target number of rows x selectivity. Here, the target number of rows is those satisfying `col2 = 5`, totaling 1,000, and the selectivity corresponds to the `col1 = 1000` condition, which is 1/5. Thus, the result is 1,000 x 1/5 = 200 rows.

From these results, we can observe that `actRows` and `estRows` are consistent.