Jag vet inte om interna funktioner i Microsoft SQL Server, men jag kan svara för MySQL, som du taggade för din fråga. Detaljerna kan variera för andra implementeringar.
Q1. Höger, inget extra utrymme behövs för det klustrade indexet.
Vad händer om du tappar det klustrade indexet? MySQL:s InnoDB-motor använder alltid primärnyckeln (eller den första icke-null unika nyckeln) som det klustrade indexet. Om du definierar en tabell utan en primärnyckel, eller om du släpper primärnyckeln för en befintlig tabell, InnoDB genererar en intern konstgjord nyckel för det klustrade indexet . Denna interna nyckel har ingen logisk kolumn som refererar till den.
Q2. En ordning av rader som returneras av en fråga som använder ett icke-klustrat index kan inte garanteras. I praktiken är det den ordning som raderna öppnades i. Om du vill att rader ska returneras i en specifik ordning ska du använda ORDER BY i din fråga. Om optimeraren kan dra slutsatsen att din önskade ordning är densamma som den ordning i vilken den kommer åt rader (indexordning, oavsett om det är klustrat eller icke-klustrat index), kan den hoppa över sorteringssteget.
F3. InnoDB icke-klustrade index har ingen pekare till motsvarande rad vid ett blad i indexet, det har värdet av primärnyckeln. Så en uppslagning i ett icke-klustrat index är egentligen två B-trädsökningar, den första för att hitta bladet på det icke-klustrade indexet, och sedan en andra sökning i det klustrade indexet.
Detta är dubbelt så mycket som kostnaden för en enda B-trädsökning (mer eller mindre), så InnoDB har en extra funktion som kallas Adaptive Hash Index . Ofta sökta värden cachelagras i AHI, och nästa gång en fråga söker efter ett cachelagrat värde kan den göra en O(1)-sökning. I AHI-cachen hittar den en pekare direkt till bladet i det klustrade indexet, så det eliminerar båda B-trädsökningar, en del av tiden.
Hur mycket detta förbättrar den totala prestandan beror på hur ofta du söker efter samma värde(n) som har sökts efter tidigare. Enligt min erfarenhet är det typiskt att förhållandet mellan hash-sökningar och icke-hash-sökningar är ungefär 1:2.
Q4. Konstruera indexen för att betjäna de frågor du behöver för att optimeras. Vanligtvis är ett klustrat index en primär eller unik nyckel, och åtminstone i fallet med InnoDB krävs detta. Varken age inte heller salary sannolikt är unik.
Du kanske gillar min presentation, Hur man designar index, verkligen .
F5. InnoDB skapar automatiskt ett index när du deklarerar en unik begränsning. Du kan inte ha begränsningen utan att det finns ett index för det. Om du inte hade ett index, hur skulle motorn säkerställa unikhet när du infogar ett värde? Den skulle behöva söka i hela tabellen efter ett dubblettvärde i den kolumnen. Indexet hjälper till att göra unika kontroller mycket effektivare.