DB2 database management system , som med de fleste relasjonsdatabaser , sysselsetter spesielle filer som kalles indekser for å fartsrekord oppslag. Mesteparten av tiden , programmer bruker en indeks for å hente en bestemt post fra en database tabell , men lar DB2 du finne flere poster som representerer et område. I sistnevnte tilfelle , oppretter en Structured Query Language setning som bruker ulikheter som er større enn eller mindre enn . Hvorfor bruke en indeks?

Uten en indeks , må en datamaskin leser hver post i en tabell før den finner en som passer et kriterium . For eksempel har en online forhandler en database tabell som inneholder 100 000 kunder. Når Joe Smith logger seg på med sin kunde-ID , vil maskinen må lese titusenvis av poster til det som ligger hans . I seg selv , tar driften noen sekunder ; multiplisert med tusenvis av kunder , blir dette timer med ekstra prosessering. En indeks lagrer bare kunden IDer i en egen fil organisert for rask tilgang. DB2 lokaliserer den ønskede posten posisjon i filen etter å ha lest noen indeks poster; med posisjonsnummer , henter den posten i hovedtabellen direkte. Ved hjelp av en indeks , finner DB2 rekord i noen få tusendeler av et sekund , i stor grad påskynde mange database oppgaver .
Likhet og ulikhet

Et typisk program bruker en likestilling å hente en indeksert posten fra en DB2-tabell , som følgende SQL-kode illustrerer : en

SELECT CUSTOMER_NAME , adresse , by, stat fROM kunder WHERE CUSTOMER_ID = '51412 ';

WHERE-leddet i SELECT-setningen tilsvarer den CUSTOMER_ID feltet til én kunde ID verdi. Av og til kan det være lurt å se poster med en rekke verdier , som i følgende SQL-setning : en

SELECT CUSTOMER_NAME , adresse , by, stat FROM kunder WHERE CUSTOMER_ID > = '51400 ';
< p> Her trekker uttalelsen mange poster fra databasen , som begynner med en som har en kunde ID større enn eller lik 51400 . Bruken av større enn eller lik symbol er et eksempel på en ulikhet . Selv om en likestilling henter poster som samsvarer en enkelt verdi , finner en ulikhet poster av større eller mindre verdi.
The Liker Operator

DB2 bruker en tabell indeks hvor mulig, men det avhenger av din SQL-setning WHERE klausulen. Dersom uttalelsen har ulikheter , kan DB2 fortsatt bruke indeksen , men effektiviteten kan lide . LIKE-operatoren illustrerer hvordan indeksen fungerer i ulike situasjoner , i kraft skaper ulikheter med sine jokertegn , " %" og den mest effektive SQL-setning velger en enkel , uavbrutt serie , som følgende SQL- show " _ ". :

SELECT CUSTOMER_NAME , adresse , by, stat FROM kunder WHERE CUSTOMER_ID sOM '514 % ';

uttalelsen finner alle postene som har customer_IDs begynner med DB2 finner den første posten som oppfyller dette kriteriet " 514 ". , henter alle etterfølgende poster som kamp , deretter stopper . Den neste SQL-setning er mindre effektive : en

SELECT CUSTOMER_NAME , adresse , by, stat FROM kunder WHERE CUSTOMER_ID LIKE ' _1400 ';

Her wildcard tegnet "_ " angir alle kundens ID-er som ende med " 1400 ", men som begynner med et tall . DB2 må søke mest av indeksen , finne alle IDer som begynner med " 1 ", " 2 " og så videre til slutten av tabellen. Indeksen sparer mindre tid i denne situasjonen.
Multi - feltet Indexes

HVOR klausuler av mange SELECT-setninger angi flere felt. Å forbedre hastigheten på disse velger , kan en indeks romme mer enn ett felt . For eksempel ser følgende SQL etter poster ved hjelp av en kombinasjon av likestilling og ulikhet operasjoner : en

SELECT CUSTOMER_NAME , adresse , by, stat FROM kunder WHERE state = ' IL ' AND zip_code > = '60600 ';
p Hvis du ofte hente data ved hjelp av de samme feltene og kriterier , lage en ny indeks som kombinerer feltene. For best mulig effektivitet , sette likestilling felt i indeksen først , etterfulgt av ulikhet felt.