Ik weet niets over internals van Microsoft SQL Server, maar ik kan antwoorden voor MySQL, die u heeft getagd voor uw vraag. De details kunnen verschillen voor andere implementaties.
Q1. Juist, er is geen extra ruimte nodig voor de geclusterde index.
Wat gebeurt er als u de geclusterde index laat vallen? De InnoDB-engine van MySQL gebruikt altijd de primaire sleutel (of de eerste niet-null-unieke sleutel) als de geclusterde index. Als u een tabel definieert zonder een primaire sleutel, of als u de primaire sleutel van een bestaande tabel laat vallen, InnoDB genereert een interne kunstmatige sleutel voor de geclusterde index . Deze interne sleutel heeft geen logische kolom om ernaar te verwijzen.
Q2. Een volgorde van rijen die wordt geretourneerd door een query die een niet-geclusterde index gebruikt, is niet gegarandeerd. In de praktijk is dit de volgorde waarin de rijen zijn geopend. Als u rijen in een specifieke volgorde wilt retourneren, moet u ORDER BY gebruiken in uw vraag. Als het optimalisatieprogramma kan concluderen dat uw gewenste volgorde dezelfde is als de volgorde waarin het de rijen zal benaderen (indexvolgorde, al dan niet op geclusterde of niet-geclusterde index), dan kan het de sorteerstap overslaan.
Q3. InnoDB niet-geclusterde index heeft geen verwijzing naar de corresponderende rij op een blad van de index, het heeft de waarde van de primaire sleutel. Dus een zoekopdracht in een niet-geclusterde index is eigenlijk twee B-tree-zoekopdrachten, de eerste om het blad van de niet-geclusterde index te vinden, en dan een tweede zoekopdracht in de geclusterde index.
Dit is het dubbele van de kosten van een enkele B-tree-zoekopdracht (min of meer), dus InnoDB heeft een extra functie genaamd de Adaptieve hash-index . Waarden waarnaar vaak wordt gezocht, worden in de cache opgeslagen in de AHI en de volgende keer dat een zoekopdracht naar een waarde in de cache zoekt, kan deze een O(1)-zoekopdracht uitvoeren. In de AHI-cache vindt het een aanwijzer rechtstreeks naar het blad van de geclusterde index, dus het elimineert beide B-tree zoekt, een deel van de tijd.
Hoeveel dit de totale prestaties verbetert, hangt af van hoe vaak u zoekt naar dezelfde waarde(n) waarnaar eerder is gezocht. In mijn ervaring is het typisch dat de verhouding tussen hash-zoekopdrachten en niet-hash-zoekopdrachten ongeveer 1:2 is.
Q4. Construeer de indexen om de query's te leveren die u moet optimaliseren. Meestal is een geclusterde index een primaire of unieke sleutel, en in het geval van InnoDB is dit vereist. Geen van beide age noch salary is waarschijnlijk uniek.
Misschien vind je mijn presentatie leuk, Hoe indexen te ontwerpen, echt .
Q5. InnoDB maakt automatisch een index wanneer u een unieke beperking declareert. U kunt de beperking niet hebben zonder dat er een index voor bestaat. Als u geen index had, hoe zou de engine dan uniek zijn als u een waarde invoegde? Het zou de hele tabel moeten doorzoeken op een dubbele waarde in die kolom. De index helpt om unieke controles veel efficiënter te maken.