Solved

What's the best way to create indexes (single/composite) on tables so that query will run much faster?

Posted on 2013-10-25
2
476 Views
Last Modified: 2013-10-29
Let's say in below two tables,

1) table_1 has unique fields col_a, col_b, col_c and
2) table_2 has unique fields col_a, col_b,col_c, col_d

col_a, col_b, and col_c are same fields on both tables.

I will create a primary key constraint on both tables (table_1 and table_2). I will create indexes on both table for performance reason as table_1 will be joined with table_2 on col_a, col_b, col_c  

table_2 has huge number of records 400 plus millions, table_1 has less than 8 millions of records.

Questions:

1) To create a primary key constraint on both tables, should I do,
     
    create unique index idx_table_1_01 on table_1 (col_a, col_b, col_c)
    then do
    alter table table_1 add constraint pk_table_1 primary key (col_a, col_b, col_c)
   
    or just run alter table statement,
   
    alter table table_1 add constraint pk_table_1 primary key (col_a, col_b, col_c)


     
    create unique index idx_table_2_01 on table_2 (col_a, col_b, col_c, col_d)
    then do
    alter table table_2 add constraint pk_table_2 primary key (col_a, col_b, col_c, col_d)
   
    or just run alter table statement,
   
    alter table table_2 add constraint pk_table_2 primary key (col_a, col_b, col_c, col_d)

2) Since I am creating unique indexes on above two tables (table_1 and table_2). Do I still need to create normal indexes on same fields on these tables as well. For example,

create index idx_table_1_02  on table_1 (col_a, col_b, col_c)
create index idx_table_2_02 on table_2 (col_a, col_b, col_c, col_d)

or there is nop need since unique indexes on same fields exist on both tables.

3) Since I will be joining table_1 with table_2, to increase performances should I create a normal index on just a single field on both tables. For example,

create index idx_table_1_03 on table_1 (col_a)
create index idx_table_2_03 on table_2 (col_a)

or should I create composite indexes to on both tables so that query will run much faster. For example,

create index idx_table_1_03 on table_1 (col_a, col_b, col_c)
create index idx_table_2_03 on table_2 (col_a, col_b, col_c)

Just a note, col_a, col_b, and col_c are same on both tables and all three columns will be used in the WHERE clause.

Please advise.


create table table_1
(
col_a   varchar2(10 byte),
col_b   varchar2(12 byte),
col_c   varchar2(50 byte),
col_d   varchar2(10 byte),
col_i    number,
col_n   date
)

create table table_2
(
col_a   varchar2(10 byte),
col_b   varchar2(12 byte),
col_c   varchar2(50 byte),
col_d   varchar2(10 byte),
col_e   varchar2(25 byte),
col_f    number,
col_g   number,
col_s   date
)
0
Comment
Question by:IT_ETL
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
2 Comments
 
LVL 77

Expert Comment

by:slightwv (䄆 Netminder)
ID: 39601300
Try creating an index on the same columns as the primary key.  See what happens.

You index fields based on how they are used in the queries that access the tables.

If all three columns will be used in all queries in '=' joins, I see no need for additional indexes.

It's next to impossible to predict 'good' indexes without knowing the applications that will be using the data.

I would start with just the PK's and possibly indexes on any foreign keys you have.

Then monitor after the app has performed some processing and add indexes on poor performing queries.
0
 
LVL 35

Accepted Solution

by:
johnsone earned 500 total points
ID: 39601620
To address your questions 1 & 2 specifically, there is no need to create a unique index on the primary key fields.  Just create a regular index and then the constraint like this:

create index idx_table_2_01 on table_2 (col_a, col_b, col_c, col_d)
alter table table_2 add constraint pk_table_2 primary key (col_a, col_b, col_c, col_d);

The constraint will ensure the uniqueness, having a unique index is redundant.

The advantage to doing it this way is that you can disable the primary key constraint (for maintenance if needed), and the index will not be dropped.  This way to enable the constraint again, it only has to scan the existing index, not rebuild the index from scratch.
0

Featured Post

Get free NFR key for Veeam Availability Suite 9.5

Veeam is happy to provide a free NFR license (1 year, 2 sockets) to all certified IT Pros. The license allows for the non-production use of Veeam Availability Suite v9.5 in your home lab, without any feature limitations. It works for both VMware and Hyper-V environments

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Introduction A previously published article on Experts Exchange ("Joins in Oracle", http://www.experts-exchange.com/Database/Oracle/A_8249-Joins-in-Oracle.html) makes a statement about "Oracle proprietary" joins and mixes the join syntax with gen…
Shell script to create broker configuration file using current broker Configuration, solely for purpose of backup on Linux. Script may need to be modified depending on OS-installation. Please deploy and verify the script in a test environment.
This video shows, step by step, how to configure Oracle Heterogeneous Services via the Generic Gateway Agent in order to make a connection from an Oracle session and access a remote SQL Server database table.
This video shows information on the Oracle Data Dictionary, starting with the Oracle documentation, explaining the different types of Data Dictionary views available by group and permissions as well as giving examples on how to retrieve data from th…
Suggested Courses

624 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question