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