Ich bin extrem langsam ORDER BY Operationen auf XML-Datentypen. Bitte ignorieren Sie die Tatsache, dass das XML im Beispiel flach ist und in einer Tabelle gespeichert werden könnte, das sind Testdaten.SQL Server ORDER BY extrem langsam für XML-Werte
Ich habe eine SQL Server-Tabelle (ID int primary identity, body XML) und haben primäre und sekundäre XML PATH-Indizes auf Körper.
in Körper Meine XML sieht wie folgt aus:
<Doc SerialNumber="000000000000000001122222" Mfg="0" Model="DXBYCD1" AcDate="5/29/2015 9:49:27 AM" />
Meine Anfrage
SELECT TOP 10
a.ID, a.Tag, a.GD, a.Body,
a.body.value('(Doc/@SerialNumber)[1]', 'nvarchar(50)') AS Serial,
a.body.value('(Doc/@Model)[1]', 'nvarchar(50)') AS Model
FROM
Asset a
ORDER BY
Model
dauert etwa 45 Sekunden mit 5 Millionen Datensätze in der Tabelle zu vervollständigen.
Die Indizes funktionieren, denn wenn ich eine WHERE-Klausel mit hinzufügen, sind die Ergebnisse fast sofort (2ms).
Ich hatte eine Menge Zeit, um Wege zu finden, XML-Indizes für schnelle ORDER BY zu verbessern. Irgendeine Hilfe?
EDIT: Es sieht aus wie der Unterschied ist WHERE der Index verwendet wird.
Wenn ich diese Klausel verwenden:
where a.body.value('(Doc/@SerialNumber)[1]', 'nvarchar(50)') = '000000000000000000000002'
es dauert etwa 90 Sekunden. Wenn ich jedoch diese Klausel verwende:
where body.exist('/Doc/@SerialNumber[. = "000000000000000000000002"]') = 1
es wird sofort abgeschlossen.
So kann ich sehen, wo SQL die Indizes besser ausnutzt, wenn der Vergleich innerhalb der xquery geschieht. In meinem ursprünglichen Fall passiert das ORDER BY auf einer Wertanweisung, und der Optimierer nimmt keinen Vorteil.
Meine aktualisierte Frage ... gibt es eine Möglichkeit, order by auf Xpath-Abfragen zu verwenden, um die Endergebnisliste zu ordnen?
Können Sie eine berechnete Spalte hinzufügen, die Modell und Index berechnet? –
Ihre Bearbeitung zeigt genau das gleiche, wie ich in der verknüpften Frage in meiner Antwort gefunden habe. Der XML-Index wird Abfragen beschleunigen, wo Sie den vollständigen Pfad verwenden, beginnend mit einem * single * Schrägstrich und die ganze Zeile nach unten ... nein '*' oder '[...]' oder irgendein anderes Zeug. Andere Abfragen schneiden noch schlechter ab als ohne Index ... Hast du das gelesen? Das ist es wert... – Shnugo
@MartinSmith Ja, das ist eine Option, und erlaubt definitiv einfacher Berichterstattung, aber sprengt die Einfügezeit, db Größe usw. Wir haben derzeit eine sehr gute EAV-Implementierung, die gegenüber dem Generieren von berechneten Spalten für alles, was wir sortieren oder filtern können von (wir erzeugen große Ansichten von der EAV) –