sql >> Database >  >> RDS >> Sqlserver

Moet ik een bitveld indexeren in SQL Server?

Overweeg wat een index is in SQL - en index is in feite een stuk geheugen dat naar andere stukken geheugen wijst (d.w.z. verwijzingen naar rijen). De index is opgedeeld in pagina's zodat delen van de index kunnen worden geladen en verwijderd uit het geheugen, afhankelijk van het gebruik.

Wanneer u om een ​​reeks rijen vraagt, gebruikt SQL de index om de rijen sneller te vinden dan het scannen van tabellen (kijkend naar elke rij).

SQL heeft geclusterde en niet-geclusterde indexen. Mijn begrip van geclusterde indexen is dat ze vergelijkbare indexwaarden op dezelfde pagina groeperen. Op deze manier kan SQL, wanneer u om alle rijen vraagt ​​die overeenkomen met een indexwaarde, die rijen retourneren vanuit een geclusterde geheugenpagina. Dit is de reden waarom het een slecht idee is om een ​​GUID-kolom te clusteren - u probeert geen willekeurige waarden te clusteren.

Wanneer u een integerkolom indexeert, bevat de SQL-index een set rijen voor elke indexwaarde. Als je een bereik van 1 tot 10 hebt, zou je 10 indexwijzers hebben. Afhankelijk van hoeveel rijen er zijn, kan dit op verschillende manieren worden gepagineerd. Als uw zoekopdracht zoekt naar de index die overeenkomt met "1" en vervolgens waar Naam "Fred" bevat (ervan uitgaande dat de kolom Naam niet is geïndexeerd), haalt SQL zeer snel de reeks rijen op die overeenkomen met "1", waarna de tabel wordt gescand om de rest te vinden.

Dus wat SQL echt doet, is proberen de werkset (aantal rijen) die het moet herhalen te verminderen.

Wanneer u een bitveld indexeert (of een smal bereik), verkleint u de werkset alleen met het aantal rijen dat overeenkomt met die waarde. Als u een klein aantal overeenkomende rijen heeft, zou dit uw werkset aanzienlijk verminderen. Voor een groot aantal rijen met een 50/50-distributie levert dit u mogelijk weinig prestatiewinst op in vergelijking met het up-to-date houden van de index.

De reden dat iedereen zegt om te testen is omdat SQL een zeer slimme en complexe optimalisatieprogramma bevat die een index kan negeren als het besluit dat het scannen van tabellen sneller is, of een sortering kan gebruiken, of geheugenpagina's kan organiseren zoals het verdomd goed wil.



  1. Dia's en voorbeelden van SQL-intersecties

  2. Beverly Hills 90210 en ZIP+4:omgaan met adressen in gegevensmodellen

  3. Een functie met tabelwaarde maken in SQL Server

  4. Kun je in postgres de standaardopmaak instellen voor een tijdstempel, per sessie of globaal?