 |
|
Index Predicates
Oracle Tips by Burleson Consulting |
As a general rule, indexes will always
increase the performance of a database query when it is able to
utilize the index, and if there is a small subset of rows required
by the query. For Oracle, indexes are recommended for two reasons:
to speed the retrieval of a small set of rows from a table, and to
“presort” result sets so that the SQL order by clause does
not cause an internal sort.
In order to use an index, the SQL optimizer
must recognize that the column has a valid value for index use. This
is called a sargable predicate, and the data types in the
column and the predicates must match to allow Oracle to use index
access. The term sargable refers to the ability of the SQL
optimizer to utilize the index.
Here are some examples of invalid predicates.
Note that the data types are mixed, and numeric columns are compared
to character strings, and vice versa.
select *
from employee
where
emp_no = "123";
Performing a math function in the where
clause can also invalidate an index.
select *
from employee
where
salary * 2 < 50000;
Also, using the not equal operator (<>) will
invalidate the index.
select *
from employee
where
dept_no <> 10;
Whenever a transformation to a field value
takes place, the Oracle database will not be able to use the index
for that column. In the examples that follow, the use of an Oracle
built-in function invalidates the standard index:
select *
from employee
where
to_char(hire_date,’YYYY’)=1998;
Using a substring function can also
invalidate an index.
select *
from employee
where
substr(last_name,1,4) = ‘FRED’;
Conversion of columns to uppercase or
lowercase can also invalidate the index. This use of the upper
function is very common on systems that perform row access on test
strings, where the end-users do not want the end users to be
concerned with case sensitivity:
select *
from employee
where
upper(last_name) = ‘JONES’;
select *
from employee
where
lower(book_title) = ‘war and peace’;
In these cases, a function-based index can be
used to allow corresponding access to the columns.
create
index
emp_upper_last_name
on
emp
(
upper(last_name)
)
;
create
index
book_title_lower
on
book
(
lower(book_title)
)
;
You can also combine the use of
function-based indexes with bitmap indexes. In the example that
follows, we convert a low-cardinality column such as item_color
(which has fewer than 20 distinct values) into a bitmap index. To
ensure easy retrieval, we index on the color in lowercase:
create
bitmap index
item_color_lower
on
book
(
lower(item_color)
)
;
Oracle date datatypes are also problematical,
and the to_char function is sometimes needed in SQL to select
dates within specific ranges. For example, our SQL may use the
to_char function to extract dates for specific years and months.
Hence, we can index on the to_char function to specify years
and month-year combinations:
select *
from customer
where
to_char(order_date,’YYYY’)=’1999’;
select * from customer
where
to_char(order_date,’MON-YY’)=’JAN-01’
;
Here we match the function-based indexes with
the date format string in the SQL statements:
create
index
cust_order_year
on
customer
(
to_char(order_date,’YYYY’)
)
;
create index
cust_order_mon_year
on
customer
(
to_char(order_date,’MON-YY’)
)
;
Next, let’s look at issues surrounding the
like parameter in SQL statements.
Problems with the like Parameter
You cannot create a function-based index
using the like parameter, because you cannot create a
function-based index on a column mask. Of course, using a like
clause will invalidate the index if the high-order item is specified
with the percent (%) wildcard:
select *
from employee
where
last_name like ‘%SON’;
The preceding query will not be able to use
the index because it begins with the “%” mask. Next, let’s explore
index usage within Oracle when a column has an uneven distribution
of values.
This is an excerpt from "Oracle High-Performance SQL Tuning" by
Donald K. Burleson, published by Oracle Press.
