Grenzwerte für die Anzahl der Zeilen in einer SQL Server-Tabelle

Gibt es harte Grenzen für die Anzahl der Zeilen in einer Tabelle in einer SQL-Server-Tabelle? Ich habe den Eindruck, dass die einzige Grenze in der physischen Speicherung liegt.

Ab wann verschlechtert sich die Performance bei Tabellen mit und ohne Index signifikant (wenn überhaupt). Gibt es eine übliche Praxis für sehr große Tabellen?

Um ein wenig Fachwissen zu vermitteln, ziehen wir die Verwendung einer Audit-Tabelle in Betracht, die Änderungen an Feldern für alle Tabellen in einer Datenbank protokolliert und sich fragt, mit welchen Arten von Wänden wir möglicherweise konfrontiert werden.

4

4 Antworten

Zusätzlich zu all den oben genannten, die gute Empfehlungen sind, dachte ich, ich würde ein wenig mehr Kontext auf dem Index/Leistungspunkt geben.

Wie oben erwähnt, ist es nicht möglich, eine Leistungsnummer anzugeben, da die Leistung je nach Qualität und Anzahl Ihrer Indizes unterschiedlich ist. Es hängt auch davon ab, welche Vorgänge Sie optimieren möchten. Müssen Sie Inserts optimieren? Oder sind Sie eher besorgt über die Abfrageantwort?

Wenn Sie sich wirklich Gedanken über die Geschwindigkeit der Einfügung machen, wird die Partitionierung, sowie eine sehr sorgfältige Indexüberlegung, der Schlüssel sein.

Die separate Tabelle Empfehlung von Tom H ist auch eine gute Idee.

2
hinzugefügt

BrianV hat Recht. Es ist schwierig, eine Regel zu geben, da diese stark davon abhängt, wie Sie die Tabelle verwenden, wie sie indiziert wird, wie die tatsächlichen Spalten in der Tabelle aussehen usw.

Was gängige Praktiken angeht ... sollten Sie bei sehr großen Tabellen eine Partitionierung in Erwägung ziehen. Dies kann besonders nützlich sein, wenn Sie feststellen, dass Sie für Ihr Protokoll normalerweise nur Änderungen in den letzten 1 Monat (oder 1 Tag, 1 Woche, 1 Jahr, was auch immer) interessieren. Sie könnten dann ältere Teile der Daten archivieren, so dass sie verfügbar sind, wenn sie unbedingt benötigt werden, aber sie werden nicht im Wege stehen, da Sie sie praktisch nie brauchen werden.

Eine andere Sache, die Sie beachten sollten, ist eine separate Änderungsprotokolltabelle für jede Ihrer tatsächlichen Tabellen, wenn Sie dies nicht bereits planen. Die Verwendung einer einzigen Protokolltabelle gestaltet sich sehr schwierig. In der Regel müssen Sie die Informationen in einem Freiform-Textfeld aufzeichnen, das nur schwer abgefragt und verarbeitet werden kann. Außerdem ist es schwierig, Daten zu betrachten, wenn Sie eine Zeile für jede Spalte haben, die geändert wurde, da Sie viele Joins durchführen müssen, um gleichzeitig auftretende Änderungen nebeneinander zu betrachten.

2
hinzugefügt

Sie haben Recht, dass die Anzahl der Zeilen durch Ihren verfügbaren Speicherplatz begrenzt ist.

Es ist schwierig, Zahlen anzugeben, da es sehr stark von der Serverhardware, der Konfiguration und der Effizienz Ihrer Abfragen abhängt.

Zum Beispiel wird eine einfache SELECT-Anweisung schneller ausgeführt und zeigt eine geringere Verschlechterung als eine Volltext- oder Proximity-Suche, wenn die Anzahl der Zeilen zunimmt.

2
hinzugefügt

Bei Audit-Tabellen besteht ein weiterer Ansatz darin, die Daten einmal im Monat (oder in der Woche, je nachdem, wie viele Daten Sie eingeben) zu archivieren. Auf diese Weise können Sie, wenn Sie einige der letzten Änderungen mit den neuen Daten neu erstellen müssen, diese gegen kleinere Tabellen und damit schneller durchführen (das Wiederherstellen von Audit-Tabellen ist fast immer eine dringende Aufgabe, die ich gefunden habe!). Aber Sie haben immer noch die Daten verfügbar, für den Fall, dass Sie jemals zurück in der Zeit gehen müssen.

1
hinzugefügt