Welche Best Practices zum Erstellen von Indizes für mehrere Bitspalten gibt es?

Question

Guten Tag,

In SQL Server 2005, ich habe eine Tabelle zahlreiche Spalten, ein paar boolean (Bit) Spalten enthält. Beispiel: Tabelle 'Person' hat Spalten ID und Spalten HasItem1, HasItem2, HasItem3, HasItem4. Diese Tabelle ist ziemlich groß, daher möchte ich Indizes erstellen, um schnellere Suchergebnisse zu erhalten.

Ich weiß, dass es nicht gut ist, einen Index für eine Bitspalte zu erstellen, also habe ich über einen Index mit allen Bitspalten nachgedacht. Die Sache ist jedoch, dass alle diese Bitspalten in der Abfrage enthalten sein können oder nicht. Da die Reihenfolge der indizierten Spalten in einem Index wichtig ist und ich nicht weiß, welche in der Abfrage verwendet werden, wie soll ich damit umgehen?

BTW, gibt es bereits Clustered-Index, den ich nicht entfernen kann.

Answer 1

Wahrscheinlich ist es einfacher für SQL, die große Tabelle mit person_id und item_id und BitValue abzufragen, dann wird eine einzelne Tabelle mit Item1, Item2, ... Item N gesucht.

Answer 2

Ich würde vorschlagen, dass dies wahrscheinlich keine gute Idee ist. Der Versuch, Felder mit sehr niedriger Kardinalität zu indizieren, führt in der Regel nicht zu schnelleren Abfragen, und Sie haben auch den Aufwand, den Index zu verwalten.

Wenn Sie in der Regel nach einem Ihrer Bitfelder mit einem anderen Feld suchen, würde wahrscheinlich ein zusammengesetzter Index für die beiden Felder von Vorteil sein.

Wenn Sie einen zusammengesetzten Index für die Bitfelder erstellen würden, würde dies nur dann hilfreich sein, wenn die zusammengesetzten Felder am Anfang des Index bereitgestellt wurden. Wenn Sie den ersten Wert nicht in den zusammengesetzten Index einschließen, wird der Index wahrscheinlich überhaupt nicht verwendet.

Wenn als Beispiel bita in 90% Ihrer Abfragen und bid in 70% und Bits b und c in 20% verwendet wurde, würde ein zusammengesetzter Index auf (bita, bitd, bitb, bitc) wahrscheinlich einen gewissen Nutzen bringen aber für mindestens 10% Ihrer Abfragen und möglicherweise sogar 40% würde der Index höchstwahrscheinlich nicht verwendet werden.

Der beste Rat ist wahrscheinlich, es mit den gleichen Datenmengen und Datenkardinalität zu versuchen und zu sehen, was der Ausführungsplan sagt.

Answer 3

Ich weiß nicht viele Besonderheiten auf SQL Server, aber im Allgemeinen Indexierung einer Spalte, die nicht eindeutige Daten hat, ist nicht sehr effektiv. In einigen RDBMS-Systemen ignoriert der Optimizer Indizes, die ohnehin unter einem bestimmten Prozentwert liegen. Daher kann der Index auch nicht existieren.

Die Verwendung eines zusammengesetzten oder mehrspaltigen Index kann helfen, aber nur in bestimmten Fällen, in denen die Filtereinschränkungen in derselben Reihenfolge wie der Index sind. Wenn Sie 'field1, field2' indexieren und suchen Bei 'field2, field1' oder einer anderen Kombination darf der Index nicht verwendet werden. Sie könnten für jeden der speziellen Suchfälle, die Sie optimieren möchten, einen Index hinzufügen. Das ist wirklich alles, was ich mir vorstellen kann. Und im Fall, dass Ihre Daten nicht sehr eindeutig sind, selbst nach Berücksichtigung aller Bitfelder, kann der Index trotzdem ignoriert werden.

Wenn Sie beispielsweise 3-Bit-Felder haben, segmentieren Sie nur Ihre Daten in 8 verschiedene Gruppen. Wenn Sie eine vernünftige Anzahl von Zeilen in der Tabelle haben, wird die Segmentierung um 8 nicht sehr effektiv sein.

Answer 4

Ich weiß nicht über 2005, aber in SQL Server 2000 (aus der Onlinedokumentation): "Spalten des Typs Bit können keine Indizes für sie haben."

Answer 5

Wie wäre es mit der Prüfsumme?

ein int Feld mit dem Namen mySum auf den Tisch hinzufügen und diese

UPDATE checksumtest SET mysum = CHECKSUM(hasitem1,hasitem2,hasitem3,hasitem4) 

Nun führen Sie einen Wert haben, der die Kombination von Bits repräsentiert.

Führen Sie in Ihrer Suchanfrage die gleiche Prüfsumme calc und stimmen Sie auf mysum ab.

Dies kann die Dinge beschleunigen.

Answer 6

Sie sollten das Design Ihrer Datenbank überprüfen. Anstatt eine Tabelle mit den Feldern HasItem1 bis HasItem # zu erstellen, sollten Sie eine Bridge-Entität und eine Master-Items-Tabelle erstellen, wenn Sie keine haben. Die Bridge-Entität (Tabelle), person_items, hätte (mindestens) zwei Felder: person_id and item_ id.

Das Entwerfen der Datenbank auf diese Weise sperrt Sie nicht in einer Datenbank, die nur N Anzahl der Elemente basierend auf Spaltendefinitionen behandelt. Sie können beliebig viele Elemente zu einer Master-Items-Tabelle hinzufügen und so viele Elemente zuordnen, wie Sie benötigen, und zwar so viele Personen, wie Sie benötigen.