79- do not create desc descending index when you see order by XXX desc - there is book donation benefit at the end of the article

We often see that the system with customers will create some descending indexes , Such as :

create index idx_xxx on tab_xxx(col_name desc);

There are multiple fields :

create index idx_xxx on tab_xxx(col_name1 desc,col_name2 desc);

In general , Each of these fields is desc An index is not required , Normally, you only need a normal index ( Get rid of desc). Let's take a look at a case I met ( The following is a simulation demonstration for the convenience of analysis ):

-- Create a object_id is null Yes 11 Bar record t1 surface :

create table t1 as select * from dba_objects where object_id is not null;

alter table t1 modify object_name not null;

update t1 set object_id = null where rownum<=11;

commit;

-- Collect the statistics

exec dbms_stats.gather_table_stats(user,'t1');

-- Currently found TOP SQL as follows :

This is a very simple paging query SQL, No, order by, The execution plan uses a full table scan , Average production system buffer gets near 9 ten thousand ( The above is used to simulate t1 The table is relatively small , Only 741 individual block, Indexes 180 About block).

Check t1 The index on the table , There is a two field to do desc Joint index of ( It should be for other businesses SQL Built ):

create index idx_t1_desc on t1(object_id desc,object_name desc);

Add hint Compulsory use idx_t1_desc Indexes , Let's see what happens :

It uses index full scan , Also traverse the index ( If object_id is null The number of records exceeds 20 individual ,null The index block of the value will be scanned first , Because there is rownum<=20, Does not traverse the entire index ,buffer gets The number will be greatly reduced ).

To optimize this SQL, I created the following index ( Or two fields are combined , Removed desc):

create index idx_t1_normal on t1(object_id,object_name);

above SQL, Don't have to add hint, Automatically use new index , The execution plan uses index range scan, The efficiency is greatly improved ,buffer gets Only 5:

Someone might say , above desc Indexes , May be for the following SQL Built :

I'll tell you , There's no need to . The ordinary index I built can also be used by this SQL Use . because oracle The optimizer for such a is desc Of order by, You can use a descending scan of a normal index (descending) The way to optimize , There is no need to create desc descending index :

If the top order by Change to order by a.object_id desc,a.object_name( One is descending order , One is the default ascending order ), under these circumstances , If in order to avoid sorting , To create (object_id desc,object_name) Such a joint index .

And the descending index has some bug, Here is MOS Search inside descending index bug Result ( The screenshot is just part of it ):

My official account article < System migration leads to SQL Performance degradation , Why ？> It's about desc Indexed bug.

Come here , Draw my conclusion :

Similar to the descending index above , Can be replaced by ordinary indexes . A normal index may be applicable to more than one SQL, The scope of application of descending index is relatively narrow , And there are some bug. To avoid unnecessary indexes and bug, It is not recommended to create all desc descending index .

To sum up, it is :

If order by One or more fields of are desc Descending , Then there is no need to create desc Descending indexed ;

If order by Multiple fields of have rise and fall , In this case, you need to create desc descending index .

Sometimes if you need to get a descending scan of the index , The optimizer has no choice , You can use index_desc Of hint To boot the optimizer , For example, the following situation , Such as :

This SQL If not hint, By default, the execution plan of full table scanning is used . Index used IDX_T1_OWNER_OBJECT_ID yes owner+object_id Two field joint index .

---

Next, let's analyze several optimization cases introduced in the book :

---

I saw several similar optimization cases in a book , It is recommended to create desc descending index , Now let's analyze :

Case study 1:

This is a basis IP Address range is a typical way to check the information of the region SQL, This SQL I wrote an article on the official account < Interval retrieval SQL Optimize -- To continue > It has been discussed in , It is mainly written in , Then match with the appropriate index .

Above this SQL, There are several problems :

First ,ip It is not appropriate to compare addresses directly with strings , There should be certain rules , convert to number Type to compare ;

secondly , In this way, if you want to build an index , Recommend creating ip_addr_end+ip_addr_start, That is, the ordinary index with the end address in front , Instead of building a descending index of the start address ;

Again , In this way, there is no problem that ascending or descending order leads to wrong results ;

Last , There is a big drawback in this way of writing , When no matching record is found , The performance will be poor .

It is recommended that you meet the business requirements of similar interval retrieval , Refer to my official account article , It has proved to be the best .

Case study 2:

The original author's optimization suggestion is :

Although it can also play an optimization role , But as my initial case study showed , This SQL Create a normal index .desc An index actually creates a functional index , This index , other SQL Maybe not .

Case study 3:

The original author of this SQL The optimization suggestion is :

The original author put the original top n The writing is changed to 4 Paged query of layer , Personally, I think it's a little superfluous :

If the original SQL It is a paged query that turns pages many times SQL, Then there is no problem with this rewrite , When the number of pages is large , More than normal paging 3 The layer standard paging writing method will greatly improve the performance ;

But the original SQL Just take top n, There is no flipping , After the rewrite SQL There will be no performance improvement due to overwriting , It's a bit rote here .

Let's talk about the suggestion of combined index , The best index combination I think is :

If doc_level<=101 Good selectivity , Then you can create class_3 + doc_level Two field combined index ;

If doc_level<=101 Poor selectivity , Then you can create class_3 + doc_writedate + doc_level 3 Field combination index ( although sql There is order by doc_writedate desc, But there is no need to add desc);

The original author's suggestion is class_3 + doc_level + doc_writedate desc 3 Field combination index , This composite index , final doc_writedate desc It doesn't make any sense , Can't filter , Nor can the sorting be removed ( Carry out the plan sort order by still ).

If doc_level No <=101, It is =101 , Then you can create class_3 + doc_level + doc_writedate, Avoid implementing planned sort order by, There is no need to add desc Of .

summary :

Unless necessary , Don't create desc descending index . Indexes , A very important theory of relational database , We also need to understand .