SELECT EXTERNAL_ORDER_NUMBER FROM XDP_ORDER_HEADERS;
EXTERNAL_ORDER_NUMBER |
1000291 |
1000292 |
1000293 |
1000294 |
1000295 |
1000296 |
1000297 |
1000298 |
1000299 |
100030 |
1000300 |
We create an index named XDP_ORDER_HEADERS_IDX on that column.
Since we know that in this column we store numbers, executing the query:
SELECT *
FROM XDP_ORDER_HEADERS
WHERE EXTERNAL_ORDER_NUMBER = 1000296;
should use our index and run faster, right?
Wrong!
The execution plan shows us that a Full Table Scan is used instead by the CBO:
Plan | IO Cost | CPU Cost | Bytes | Cost |
SELECT STATEMENT CHOOSE | 7.505 | 835,979,287 | 190 | 8.35 |
1 TABLE ACCESS FULL DP.XDP_ORDER_HEADERS | 7.505 | 835,979,287 | 190 | 8.35 |
Since this column is of VARCHAR2 type, we should compare it with VARCHAR2 values, if we want the right index to be used.
So, the query that will take use of our index is the following:
SELECT *
FROM XDP_ORDER_HEADERS
WHERE EXTERNAL_ORDER_NUMBER = '1000296';
Plan | IO Cost | CPU Cost | Bytes | Cost |
SELECT STATEMENT CHOOSE | 4 | 23.04 | 190 | 5 |
2 TABLE ACCESS BY INDEX ROWID XDP.XDP_ORDER_HEADERS | 4 | 23.04 | 190 | 5 |
1 INDEX RANGE SCAN NON-UNIQUE XDP.XDP_ORDER_HEADERS_IDX | 3 | 14.482 | 4 |
No comments:
Post a Comment