Which fields should I add to secondary index?
Whether all the fields in the where clause should be part of secondary index?
How many distinct values we have in the table for a particular column combination to be
added in index?
Whether adding another column to existing secondary index will increase or decrease the
performance?
Which secondary index would be utilized by the database optimizer? Do & Don’t
Transaction DB05 is can:

Determine the cardinality of column combinations. This answer the question as to which the adding of another column to
the index actually increases the selectivity of the index.

Display unequal distributions in the column values. It is displayed how many values there are for the individual column
values or combinations of column values.
Transaction DB05 is very often used before recommending multiple indexes from a combination of rather unselective
columns, if the corresponding table is not too large.
Warning
This procedure is not suitable for large tables because the entire table is read. Depending on the size of the table this is
very expensive.
How to select which index fields should be used to improve performance:
DB05 – Enter the possible fields which you are using in your program –
My program was using COMP_CODE and KOSTL but creating index on comp_code/KOSTL
was not much useful.
General
In above example, the system will still have to read 100000 records for 2 cost centers and
there are just 4378 distinct values which is not even 2% of the records.
So, to improve this we can omit company code first to increase distinct values and add more
fields if we are aware or using other fields as well.
General
Try with different fields such that the first column distinct values are close to total no.
of rows or atleast 5% of the total records.
How your secondary index should look like:
1.
2.
3.
4.
No overlapping i.e. avoid redundant fields.
Should not have more than 5 indexes in any table.
Max. 4 fields
If you are adding any field in existing index then preceeding fields must be part of
where clause.
5. More distinct rows i.e.
The field or fields of the new secondary index are so selective that each
index entry corresponds to at most 5% of the total number of table entries.
Otherwise, it is not worth creating the index.
6. The database table is accessed mainly for reading entries.
7. An index can only support search criteria which describe the search
value positively, such as EQ or LIKE.
8. Avoid negation operator like NE
9. Avoiding OR conditions
General
The optimizer generally stops if the WHERE condition contains an OR expression.
In other words, it does not evaluate the fields in the OR expression with reference
to the index.
An exception to this are OR statements standing on their own. Try to reformulate
conditions containing an OR expression for one of the indexed fields. For example,
replace:
SELECT * FROM SPFLI
WHERE CARRID = 'LH'
AND
(CITYFROM = 'FRANKFURT' OR
CITYFROM = 'NEW YORK').
with:
SELECT * FROM SPFLI
WHERE (CARRID = 'LH' AND CITYFROM = 'FRANKFURT')
OR
1.
2.
3.
4.
5.
6.
7.
(CARRID = 'LH' AND CITYFROM = 'NEW YORK').
SELECT SINGLE belnr FROM bkpf INTO bkpf-belnr
WHERE bukrs = t_input_invoice-detenteur_compte_banc
AND gjahr = w_gjahr
AND blart = 'ZR'
AND bstat IN r_bstat
AND xblnr LIKE w_bktxt
%_hints oracle 'INDEX("BKPF" "BKPF~1")'.
One example provided:https://wiki.scn.sap.com/wiki/display/maxdb/transaction+db05?original_fqdn=wiki.sdn.sap.co
m&bc=true
http://help.sap.com/abapdocu_70/en/ABENINDICES.htm
General
Important discussion whether client field should be part of index?
https://archive.sap.com/discussions/thread/2081502
Conclusions:
Database cost-based optimizer does not require MANDT field to be included in index for
selection by DB system.
Secondary index with or without MANDT results in same performance.
I tend to believe that using MANDT is generally not a good idea, since production
environments tend to be single-client, and even in multiple client situations MANDT
cardinality is usually so low relative to the other fields you're using that MANDT would tend to
be a wasted hop in the index tree anyway.
Adv: Exceptional select statements requiring join on client field or client specific data
retrievals or system containing multiple clients so for historical reasons SAP included client in
their indexes.
Disadv: Unnecessary overhead in updating index table and extra space required for index
tables. Don’t include MANDT in case production system uses only single client.
Adv:
Which secondary index will run better – you can identify this without making any
changes to your program and them moving to quality system to verify the
improvement
Using SE16H to analyze the data based on fields i.e. KDS
DB20 / DB05 / DB02 / TAANA
Good selectivity is when by specifying the key values the returned rows can be reduced
significantly, to a small fraction of the overall number of rows in the table.
DB05 shows you the number of distinct values and the distribution. The more distinct values, the
better.
Check this : https://archive.sap.com/discussions/message/3734171#3734171
General
Identify fields which are not increasing the selectivity as you go down the list as these may not
add much value to the index. Consider excluding them from the index.
The numbers to the right under 101-1000...100,101-1,000,000 etc mean that a particular
search string value occurs so many times. The higher the number under these columns,
the likelihood of fetching a high number of records for a particular value.
General