Die Beschleunigung von SQL-Abfragen mit Indizes

Ich habe eine Tabelle namens Products.

Diese Tabelle enthält über 3 Millionen Einträge. Jeden Tag kommen etwa 5.000 neue Einträge. das passiert nur während der Nacht in nur 2 Minuten.

Aber diese Tabelle wird abgefragt jede Nacht vielleicht über 20 000 mal mit dieser Abfrage. 

SELECT Price 
FROM Products 
WHERE Code = @code 
  AND Company = @company 
  AND CreatedDate = @createdDate

Tisch Struktur:

Code          nvarchar(50)
Company       nvarchar(10)
CreatedDate   datetime

Kann ich sehen, dass diese Abfrage dauert etwa eine Sekunde, um ein Ergebnis zurückgeben von Products Tabelle.

Gibt es keine productId Spalte in der Tabelle ist nicht erforderlich. Es gibt also keinen Primärschlüssel in der Tabelle.

Ich würde gerne irgendwie verbessern diese Abfrage, damit das Ergebnis schneller.

Ich habe noch nie verwendet die Indizes vor. Was wäre der beste Weg für die Verwendung von Indizes für diese Tabelle?

Wenn ich eine primary key-glaubst du, es würde beschleunigt den Abfrage-Ergebnis? Halten Sie im Verstand, dass ich immer noch zur Abfrage der Tabelle, indem Sie 3 Parameter, wie 

WHERE Code = @code 
  AND Company = @company 
  AND CreatedDate = @createdDate.

Dies ist obligatorisch.

Als ich erwähnte, dass der Tisch bekommt neue Einträge in 2 Minuten jeden Tag, während der Nacht. Wie würde sich das auf die Indizes?

Wenn ich Indizes, die Spalte wäre die beste zu verwenden und ob ich den verwenden Sie clustered oder non-clustered-Indizes?

  • finden Sie heraus, fehlende Indizes auf der Tabelle mit tuning advisor oder Create Clustered Index auf eine Spalte, die mehr tun, DML-Operationen, und Erstellen Sie Nicht Gruppierte Index zusammen mit Abdeckenden Indizes
  • Bekommen Sie einen index-Vorschlag, wenn Sie die Anzeige der geschätzten Ausführungsplan der Abfrage im SSMS?
  • Ich würde einen NCI auf (CreatedDate, Company, Code) INCLUDE(Price).
  • "Es gibt also keinen Primärschlüssel in der Tabelle." - Jede Tabelle sollte einen Primärschlüssel haben, auch wenn es nur ein Ersatzschlüssel. @wewesthemenace index sieht entsprechende.
  • die Abfrage wird ausgeführt durch die Konsole-Anwendung. nie verwendet-Ausführung plan im ssms @Beil.
  • danke für den Vorschlag, aber würde erklären, dass Ihre Abfrage ein bisschen mehr. vielleicht Antworten als eine Antwort mit Abfrage wewesthemenace
  • Ich werde fügen Sie einen Primärschlüssel in der Tabelle Dank Mitch Weizen und das Ergebnis sehen.
  • Sollte jede Tabelle über einen gruppierten index verfügen, oder zumindest in einem Fall die Tabelle wird aktualisiert / gelöscht werden, denn das kann schwerwiegende Fragmentierung und verschwendet Platz in der Tabelle
  • Hallo @akdurmus, hier ist ein allgemeiner Tipp für die Beschleunigung von Abfragen: SQL-Management-Studio (SSMS) können Sie die option "Show ACTUAL Execution Plan". (sicher sein, es ist tatsächlich, nicht geplant), Dann starten Sie Ihre Abfrage, und danach sehen Sie den Ausführungsplan in einem separaten tab. Sie können dort sehen, was passiert in Ihrer Abfrage, und warum es so langsam ist. Auch erkennt das system, dass ein wichtiger index fehlt, und es wird Ihnen zeigen, die create index statement, das beschleunigt die Abfrage.
  • PS: Es hilft wirklich, zu lernen, zu verstehen, die Durchführung planen und wie Sie Indizes und Tabellen arbeiten. Sie werden sehen, es ist nicht so viel Magie, aber es ist immer wichtig, zu verstehen, wie die mechanik funktioniert. Sobald Sie das wissen haben, können Sie sich unglaubliche Geschwindigkeiten aus der Datenbank!

InformationsquelleAutor akd | 2015-06-15
  1. 11

    Den besten, was zu tun wäre, hängt davon ab, welche anderen Felder die Tabelle hat und was andere Abfragen ausführen, die gegen die Tabelle.

    Ohne weitere details, ein non-clustered-index auf (code, Firma, createddate), die den "Preis" - Spalte, wird sicherlich die performance verbessern.

    CREATE NONCLUSTERED INDEX IX_code_company_createddate
ON Products(code, company, createddate)
INCLUDE (price);

    Das ist, weil, wenn Sie, dass der index in Ort, dann die SQL nicht auf die tatsächliche Tabelle, wenn die Abfrage ausgeführt, wie die es finden kann alle Zeilen mit einem bestimmten "code, Firma, createddate" im index und es wird in der Lage sein, das zu tun, wirklich schnell, da der index ermöglicht es, gerade für den schnellen Zugriff, wenn die Felder, die den Schlüssel definieren, und es wird auch der "Preis" - Wert für jede Zeile.

    Bezüglich der Einsätze, der für jede Zeile Hinzugefügt, SQL-Server hinzufügen, um den index als gut, so dass die performance für die Einsätze beeinflusst werden. In denke, Sie sollten erwarten, dass die Gewinne, die auf SELECT-performance überwiegen die Auswirkungen auf die Einsätze, aber Sie sollten das testen.

    Außerdem werden Sie mit mehr Raum als der index gespeichert werden alle Felder jeder Zeile neben dem Platz, der von der ursprünglichen Tabelle.

    Wie andere schon angemerkt in den Kommentaren, das hinzufügen einer PK auf den Tisch (auch wenn das bedeutet, dass das hinzufügen einer Spalte ProductId Sie eigentlich nicht müssen) vielleicht eine gute Idee als gut.

    • Wenn es mir war, würde ich die Reihenfolge umkehren: CreatedDate,Company,Code.
    • Danke ich werde versuchen Sie dies und sehen Sie die Auswirkungen auf die Leistung.
    • Kann nicht glauben, dieser. Der Prozess beschleunigt wie nitro. vielen Dank. ja, wie Sie erwähnt haben, dass das einfügen war etwa 2 Minuten vor und nach dem erstellen des index dauert es etwa 8 Minuten. aber die select-Abfrage verkürzen von 2 Stunden auf 5 Minuten. nicht glauben kann 🙂
    • Nun sehen Sie die Magie eines index 😉 natürlich: Wenn man 3 Millionen Datensätze, und KEIN index, dann die Datenbank muss auf SCANNEN auf den Tisch; das bedeutet, dass 3 Millionen Zugriffe, im Durchschnitt 1,5 Millionen ! Aber wenn Sie über einen index, dann die Datenbank muss nur 1 bis 3 (!) Festplatten-Zugriffe ! Ein index funktioniert ähnlich wie der index in einem Buch: Sie sehen den ersten Brief, dann den 2., und dann sind Sie schon da.
    InformationsquelleAutor eugenioy
Schreibe einen Kommentar