Oracle Table Indexes

Question

Hello.
I'm in the process of putting some indexes on tables for performance improvement of queries run.
eg the foll query -
SELECT MPH_ENTITY_ID, MPH_PRICE_DT, MPH_STCK_EXCHNG_ID, BPT_BP_SHRT_NM, MPH_SEC_ID, SEC_SEC_NM, NMS_SEC_NUM, MPH_PRICE_TYP, MPH_MKT_PRC, MPH_VENDOR, MPH_PRICE_TIME, MPH_EXCHNG_RATE, MPH_DENOM_UNIT, MPH_LOCL_CNC_EQVU, MPH_INDCTV_PRC_IND, MPH_VLM_TRDD, MPH_MRKT_CPTL, MPH_MKT_PRICE_HSTRY_VER, BPT_BSNS_PRTNR_VER, SEC_SEC_MASTER_VER FROM MPH_MKT_PRICE_HSTRY left outer join NMS_NUM_SCHEME on NMS_SEC_ID=MPH_SEC_ID AND NMS_NUM_SCHM='CUSIP',BPT_BSNS_PRTNR,SEC_SEC_MASTER WHERE MPH_ENTITY_ID=BPT_ENTITY_ID AND MPH_STCK_EXCHNG_ID=BPT_BP_ID AND MPH_SEC_ID=SEC_SEC_ID ORDER BY MPH_SEC_ID DESC
The Explain plan in PL/SQL developer shows "Table Access Full" scan for 2 tables - BPT_BSNS_PRTNR AND MPH_MKT_PRICE_HSTRY.
I created the foll 2 indexes and now the explain plan shows "index fast full" scan on these tables -
1) create index mph_3 on mph_mkt_price_hstry(MPH_ENTITY_ID, MPH_PRICE_DT, MPH_STCK_EXCHNG_ID, MPH_SEC_ID, MPH_PRICE_TYP, MPH_MKT_PRC, MPH_VENDOR, MPH_PRICE_TIME, MPH_EXCHNG_RATE, MPH_DENOM_UNIT, MPH_LOCL_CNC_EQVU, MPH_INDCTV_PRC_IND, MPH_VLM_TRDD, MPH_MRKT_CPTL, MPH_MKT_PRICE_HSTRY_VER);
2) create index BPT_8 on bpt_bsns_prtnr(BPT_BP_SHRT_NM,BPT_BSNS_PRTNR_VER,BPT_ENTITY_ID,BPT_BP_ID);
My question here is that I have included columns in the select clause also in the indexes and the scan type has improved from table access full to index fast full scan. Is this correct ? Should select columns be also a part of indexes ? My take was that indexes contain columns in "where" clause or columns where joins are implemented and not select columns.
Please suggest.

Answer 1

An Index that includes all the columns of the SELECT clause with those of the WHERE clause is a "skinny table".
Using such an Index avoids accesses to the table entirely.
There are situations where the DBA or Designer may choose to create such an Index.
Downsides ?*
If there are too many columns in the Index, the Index itself may become too large. When the index is too large for Oracle to be able to cache blocks, Oracle may have to undertake multiple single block read calls to the OS if accessing many rows. This can make the index counter-productive.
Index maintenance overheads increase -- the probability that the index also has to be updated with every UPDATE statement on the table increases. Also, every INSERT and DELETE makes that much more effort updating the Index Leaf Blocks (ie the size of the update to the Index is larger, the Index Key being larger).
Some queries might be executed using Skip Scan Search of the index when, properly, it might have made more sense to put those query columns in a seperate index.