Ich habe eine Tabelle ItemValue voll von Daten auf einem Server SQL 2005 im Jahr 2000 Kompatibilitätsmodus ausgeführt wird, der so etwas wie (es ist eine benutzerdefinierte Werte Tabelle) aussieht:SQL-Optimierung - Änderung des Ausführungsplans basierend auf dem Constraint-Wert - Warum?
ID ItemCode FieldID Value
-- ---------- ------- ------
1 abc123 1 D
2 abc123 2 287.23
4 xyz789 1 A
5 xyz789 2 3782.23
6 xyz789 3 23
7 mno456 1 W
9 mno456 3 45
... and so on.
von fieldID kommt die Itemfield Tabelle:
ID FieldNumber DataFormatID Description ...
-- ----------- ------------ -----------
1 1 1 Weight class
2 2 4 Cost
3 3 3 Another made up description
. . x xxx
. . x xxx
. . x xxx
x 91 (we have 91 user-defined fields)
Weil ich im Jahr 2000 Modus nicht drehen kann, sind wir eine hässliche Abfrage mit CASEs und GROUP BY die Daten zu erhalten Gebäude stecken schauen, wie es sollte für s ome legacy apps, das ist:
ItemNumber Field1 Field2 Field3 .... Field51
---------- ------ ------- ------
abc123 D 287.23 NULL
xyz789 A 3782.23 23
mno456 W NULL 45
Sie können sehen, dass wir nur diese Tabelle benötigen, um Werte bis zur 51. UDF anzuzeigen. Hier ist die Abfrage:
SELECT
iv.ItemNumber,
,MAX(CASE WHEN f.FieldNumber = 1 THEN iv.[Value] ELSE NULL END) [Field1]
,MAX(CASE WHEN f.FieldNumber = 2 THEN iv.[Value] ELSE NULL END) [Field2]
,MAX(CASE WHEN f.FieldNumber = 3 THEN iv.[Value] ELSE NULL END) [Field3]
...
,MAX(CASE WHEN f.FieldNumber = 51 THEN iv.[Value] ELSE NULL END) [Field51]
FROM ItemField f
LEFT JOIN ItemValue iv ON f.ID = iv.FieldID
WHERE f.FieldNumber <= 51
GROUP BY iv.ItemNumber
Wenn die Sachgebietsnr Einschränkung < ist = 51, führen der Plan geht so etwas wie:
SELECT <== Computer Scalar <== Stream Aggregate <== Sort (Cost: 70%) <== Hash Match <== (Clustered Index Seek && Table Scan)
und es ist schnell! Ich kann mehr als 100.000 Datensätze in einer Sekunde abrufen, was unseren Bedürfnissen entspricht.
Allerdings, wenn wir mehr UDFs haben und ich die Einschränkung auf alles über (ja, ich testete sie eins nach dem anderen) oder wenn ich es vollständig entfernen, verliere ich die Sortierung im Ausführungsplan, und es wird durch eine ganze Reihe von Parallelism-Blöcken ersetzt, die Ströme sammeln, neu partitionieren und verteilen, und das Ganze ist langsam (30 Sekunden für gerade einmal 1 Datensatz).
Sachgebietsnr hat einen gruppierten, eindeutigen Index, und einen Teil des zusammengesetzten Primärschlüssels mit dem ID Säule (nicht gruppierten Index) in der Itemfield Tabelle ist. Die ItemValueID und ItemNumber Spalten der Tabelle machen eine PK, und gibt es eine extra nicht gruppierten Index auf der ItemNumber Spalte.
Was ist der Grund dafür? Warum ändert sich durch die Änderung meiner Integritätsregel für einfache Ganzzahlen der gesamte Ausführungsplan?
Und wenn Sie dran sind ... was würden Sie anders machen? Es ist ein SQL-Upgrade für ein paar Monate geplant, aber ich muss dieses Problem vorher beheben.
Was ich anders machen würde, ist nicht diese Tabellenstruktur zu verwenden. Es ist viel besser, eine Struktur mit definierten Feldern für die 99% der Datenbedürfnisse zu verwenden, die im Voraus herausgefunden werden können, als eine EAV-Tabelle zu verwenden. Übrigens verhindert der Kompatibilitätsmodus nicht die Verwendung neuer Funktionen, sondern erlaubt die Verwendung von Funktionen, die nicht mehr erlaubt sind. Wenn Sie jedoch auf einer 2005-Datenbank mit einer 2000-Produktionsdatenbank entwickeln, ist es am besten, die neuen Features zu vermeiden. – HLGEM