Indexes for 'greater than' queries

浪子不回头ぞ 提交于 2020-08-02 09:23:11

问题


I have several queries, most of them being:

select * from Blah where col > 0

and

select * from Blah where date > current_date

Since they're both kind of a range, would an unclustered b+ tree index on col and date be a good idea to speed up the queries? Or a hash index? Or would no index be better?


回答1:


Creating an INDEX on the column used in the filter predicate as a date range condition should be useful as it would do a INDEX RANGE SCAN.

Here is a demonstration about How to create, display and read EXPLAIN PLAN in Oracle.

Let's see the test cases for both scenarios:

Test# 1 : Without index

SQL> EXPLAIN PLAN FOR
  2  SELECT * FROM emp WHERE hiredate > to_date('01/04/1981','mm/dd/yyyy');

Explained.

SQL>
SQL> SELECT * FROM TABLE(dbms_xplan.display);

PLAN_TABLE_OUTPUT
-----------------------------------------------------------------------------------------------
Plan hash value: 3956160932

--------------------------------------------------------------------------
| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |      |    14 |   518 |     3   (0)| 00:00:01 |
|*  1 |  TABLE ACCESS FULL| EMP  |    14 |   518 |     3   (0)| 00:00:01 |
--------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

PLAN_TABLE_OUTPUT
-----------------------------------------------------------------------------------------------

   1 - filter("HIREDATE">TO_DATE(' 1981-01-04 00:00:00', 'syyyy-mm-dd
              hh24:mi:ss'))

14 rows selected.

SQL>

Test# 1 : With index

SQL> CREATE INDEX emp_idx ON emp(hiredate);

Index created.

SQL>
SQL> EXPLAIN PLAN FOR
  2  SELECT * FROM emp WHERE hiredate > to_date('01/04/1981','mm/dd/yyyy');

Explained.

SQL>
SQL> SELECT * FROM TABLE(dbms_xplan.display);

PLAN_TABLE_OUTPUT
-----------------------------------------------------------------------------------------------
Plan hash value: 3589413211

-----------------------------------------------------------------------------------------------
| Id  | Operation                           | Name    | Rows  | Bytes | Cost (%CPU)| Time     |
-----------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                    |         |    14 |   518 |     2   (0)| 00:00:01 |
|   1 |  TABLE ACCESS BY INDEX ROWID BATCHED| EMP     |    14 |   518 |     2   (0)| 00:00:01 |
|*  2 |   INDEX RANGE SCAN                  | EMP_IDX |    14 |       |     1   (0)| 00:00:01 |
-----------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):

PLAN_TABLE_OUTPUT
-----------------------------------------------------------------------------------------------
---------------------------------------------------

   2 - access("HIREDATE">TO_DATE(' 1981-01-04 00:00:00', 'syyyy-mm-dd hh24:mi:ss'))

14 rows selected.

SQL>

So, in the second test case, you see an index range scan. I would suggest you to do a similar test on your environment too.




回答2:


Yes. If you index on any column and are only filtering on that column the index will be used.

The question is pretty vague. Maybe with more code or a bigger example, more help could be given around the performance benefits on a specific query.

In your case an index on col (first query) and date (second query) would speed up those specific queries.



来源:https://stackoverflow.com/questions/29823586/indexes-for-greater-than-queries

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!