Der findes en facilitet i DB2 optimizeren kaldet index-screening, som er en rigtig god ide, men som mange ikke kender til. Index-screening er evnen til at udnytte en kolonne i et index, selvom der ikke er match på kolonnen før. DB2 optimizeren skilter ikke med, at den udnytter kolonner i et index, der ikke nødvendigvis er match på. Man er simpelthen nødt til at vide, at DB2 benytter index-screening.

Lad os antage en tabel T med kolonnerne A, B, C, D, E, F og G. På tabellen er der defineret et index bestående af D, A, G i den angivne rækkefølge. Følgende SQL-kald udstedes nu mod tabellen:

SELECT *
FROM T
WHERE D = 5 AND G = 7

En explain af SQL-kaldet vil sandsynligvis afsløre, at DB2 vil udnytte den første kolonne i indexet (matchcols=1), men aldrig nogensinde, at den også vil udnytte kolonne G, da DB2 jo er nødt til at scanne alle index-entries med D=5 for at finde dem med G=7. Det skyldes, at matchcols kun fortæller noget om, hvor mange kolonner DB2 kan udnytte i et index uden at scanne.

Lad os antage samme SQL-kald som før, dog uden betingelsen D=5. Her vil en explain måske vise, at DB2 vil foretage et index-scan (matchcols=0). Dette er det eneste tilfælde, hvor DB2 rent faktisk afslører, at index-screening anvendes. Og det er faktisk en rigtig god ide, hvis en lille procentdel af rækkerne i T indeholder værdien 7 i kolonne G og indexet er meget mindre end selve tabellen.

Man skal derfor altid overveje at medtage kolonner i sine betingelser, hvis de indgår i et index, selv om de ikke står først i indexet. Det gælder især, hvis der er tale om opslag mod rigtig store tabeller. Og man kan spare at oprette nye indexer, hvis man kan udnytte kolonner i eksisterende indexer. Det går måske ikke helt så stærkt som med et skræddersyet index, men det er jo ikke altid, at et ekstra index vækker den store jubel.