När du vill ha den maximala hämtningshastigheten och har båda kolumnerna i join eller där villkor, MEN ibland har kolumn a högre selektivitet och ibland har kolumn b högre selektivitet, och du vill dra nytta av det faktumet från ett enda index.
Jag tror också att ditt förhållande mellan datastorlek och maskinens prestanda bör vara ganska högt och samtidigt måste du (gissningsvis) vara villig att kalla varje förbättring som en nödvändighet (även om det bara är några få procent).
Ändå lär erfarenheten att saker beror på många faktorer; med specifika RDBMS och applikationsmiljöer kan du bättre köra dina egna benchmarks.
EDIT:Ytterligare förklaring på sammansatta index.från wikipedia
:
"Orden i vilken kolumner listas i indexdefinitionen är viktig. Det är möjligt att hämta en uppsättning radidentifierare med endast den första indexerade kolumnen. Det är dock inte möjligt eller effektivt (på de flesta databaser) för att hämta uppsättningen radidentifierare med endast den andra eller högre indexerade kolumnen.
Tänk dig till exempel en telefonbok som är organiserad efter stad först, sedan efter efternamn och sedan efter förnamn. Om du ges staden, kan du enkelt extrahera listan över alla telefonnummer för den staden. Men i den här telefonboken skulle det vara väldigt tråkigt att hitta alla telefonnummer för ett givet efternamn. Du skulle behöva leta i varje stad avsnitt för poster med det efternamnet."
Wikipedias förklaringar är kanske alltför förenklade, men det ger dig den grundläggande idén (tänk på att telefonböcker vanligtvis har klustrade index och att det inte skulle vara ditt allmänna databasindex).
Beroende på storleken på indexet kontra storleken på datastrukturen kontra tillgängligt minne kontra selektiviteten i den första kolumnen i indexet kan det fortfarande vara mycket billigare att använda felaktigt ordnat index än att använda tabellskanningar.
Ah, tänkte bara på en bättre liknelse med ett exempel du letar efter Föreställ dig en trevlig lärobok, den skulle ha innehållsförteckning med kapitel och underkapitel och numret på sidorna där de finns (vilket är ett icke klustrat index som innehåller pekare till dataposter - sidor). Föreställ dig nu att läroboken är på SQL-92-standarden, då skulle de flesta termerna i TOC vara SQL-termer (håller det här antagandet). Du skulle också ha ett annat index i slutet av boken som skulle lista alla intressanta termer i alfabetisk ordning (låt oss anta med större kapitelnamn) och sidnummer.
För frågor som "Berätta för mig alla kapitel under vilka DISTINCT visas" skulle du använda det andra indexet. (eftersom selektiviteten i det senare fältet är hög)
För frågor som "Berätta för mig numret på termerna som visas under första kapitlet" skulle du använda innehållsförteckningen
Så för frågor som 'Beskrivs SELECT under DML-kapitlet?' du kan använda något av indexen. (eftersom selektiviteten för båda fälten är hög) Men om TOC för DML själv är 3 sidor lång och SELECT-posten i indexet bara har femton rader skulle du förmodligen gå till den andra, och det är ett exempel på när du drar nytta av båda indexen.
Om du nu tycker att det är för långsökt, ta då hänsyn till en databas av kongressens skannade bibliotek. :)
Som jag sa tidigare är all planering bra, men kör dina egna riktmärken i slutet.