Code Optimieren?

Die SQL abfrage ist schon optimiert

vorher:

SELECT * FROM Archive WHERE BEETWEN DateA AND DataB AND (TagID=1 OR TagID=2 OR TagID=3 OR TagID=4);

nachher:

SELECT * FROM Archive WHERE BEETWEN DateA AND DataB AND TagID IN (1,2,3,4);

Der Witz ist , das er bei der ersten Abfrage "ExecuteQuery" um ein vielfaches langsamer ist als bei der zweiten variante.. die schleife s.o. ist aber immer noch gleich langsam....

hustbaer

Falls du mit SQL Server arbeitest, dann sollten beide Abfragen gleichwertig sein, auch was die Performance angeht.

Davon abgesehen brauchst du einen Index auf das Datumsfeld welches du hier unterschlagen hast und/oder auf das TagID Feld. Bzw. auf beide.

Je nachdem welches Kriterium selektiver ist.

Ideal wäre vermutlich:

Falls TagID selektiver als das Datum ist
Index = TagID, Datum
ansonsten
Index = Datum, TagID

Und wenn die selekivität mal da und mal dort höher ist (je nach Datums-Bereich z.B.), dann einfach beide Indexe anlegen.

EXDW

vieleicht ist es auch besser die ids erst ab zu fragen, das der datumsbereich erst geprueft wird wenn die ids zustimmen

SELECT * FROM Archive WHERE TagID IN (1,2,3,4) AND BEETWEN DateA AND DataB;

Das würde mich sehr wundern, wenn MSSQL nicht selber weiss, welche Reihenfolge für ihn besser ist.
Aber im Management Studio sieht man ja immer schön, wielange er wofür brauch.
Ausprobieren kostet ja nix.

witte

Mr Evil schrieb:

vieleicht ist es auch besser die ids erst ab zu fragen, das der datumsbereich erst geprueft wird wenn die ids zustimmen

SELECT * FROM Archive WHERE TagID IN (1,2,3,4) AND BEETWEN DateA AND DataB;

Ein guter Anfrageoptimierer sollte sowas aber selbstständig tun. Er wird sicherlich dieselbe Anfragestrategie verwenden egal wie rum man es schreibt.

hustbaer

Natürlich ist die Reihenfolge wie man es schreibt egal

SQL Server verwendet den Index, von dem er schätzt dass er selektiver ist. Bzw. wenn es nur einen gibt, dann nimmt er eben den. Und wenn es garkeinen gibt, dann macht es auch genau garkeinen Unterschied, ob zuerst die ID oder zuerst das Datum geprüft wird, da ein Table-Scan sowieso immer langsam ist (ausgenommen relativ kleine Tabellen).

Es würde mich sogar ziemlich wundern, wenn es einen Unterschied zwischen "IN" und "= k1 OR = k2 OR = k2..." gibt - in meinen Tests hat das immer zum gleichen Execution-Plan geführt.

Guten Morgen,

ich verwende den SqlCeServer , das is doch ne lite Variante eine SQLServers.. !?

Ne Hustbaer, irgendwie braucht die "ExecutionQuery" ungefähr genausolange wie das iterieren des DataReaders wenn ich ".... AND (TagID=1, TagID=2, TagID=3,TagID=4)" statt ".. AND TagID IN(1,2,3,4)" als ob er das die Datenbank mehrmals durchlaufen würde.

Ich habe Indexe auf Datum und TagID Spalten.

Die Datenbank is ca 45MB groß und hat so 400.000 bis 500.000 Einträge.

hustbaer

OK, mit SQL Server CE hab' ich keine Erfahrungen. Auf dem grossen ist es - soweit ich es beobachten konnte - egal.

Wieviele Records liefert die Abfrage denn als Ergebnis?
Und welche Indexe hast du definiert?

Hab Indexe auf den Zeitstempel und auf die TagID, wie du erwähnt hast!

Die DAtenbanken liefern so 40.000- 60.000 Datensätze

Ich hab mal einen Test gemacht, und zwar hab ich die "TagID" where Klausel weg gelassen, so das alle Daten in nem best. Zeitbereich zurückgegben werden.

Dann hab ich in der "OleDBReader" Schleife, die TagIDs mal manuel verglichen, hab also bei jeder Iteration mit ner simplen Ling- Query geprüft ob die "TagID" in Bedingung steht.

Nun braucht die ganze Geschichte 30% mehr zeit, als wenn ich die selektion von dem SqlCeEngine erledigen lassse. Was auch logisch ist, das ne Datenbank ja schneller sein sollte.

Wenn ich nun Spasseshalber meine "Linq-Query" weg lasse, also ALLE Datensätze zurückgebe in dem best. Zeitraum, geht es NOCH Länger! Doppelt so lange! das heist die

while(reader.Read())
{
  ....=  reader.GetInt16();
 ...
}

schleife der OleDbReader ist der Flaschenhals???

volkard

Wieviel Zeit geht eigentlich fürs DateTime.FromOADate(time) drauf?

Der Aufwand für DateTime.FromOADate(time) ist minimal...

hustbaer

NullBockException schrieb:

das heist die (...) schleife der OleDbReader ist der Flaschenhals???

Nö. Bzw. ja, wie man's sieht: es heisst SQL Server CE is anscheinend scheisse langsam

Vom SQL Server (ohne CE) bekomme ich auf jeden Fall mehrere zigtausend Rows pro Sekunde... (bei einfachen Abfragen, und "normal" breiten Tabellen).

Hmm ohje, was hab ich mir da anquatschen lassen mit dem SQL CE Server:) Muss wohl mal paar Performance Tests machen. Vll. mal die gute allte Access Datenbank verwenden;)

Was mir auch noch auffällt ist, das ich mehrere SQLC CE datenbanke parallel offen habe, aber das düfte ja die Perfomance einer abfrage auf eine einzelen DB nich verlangsamen oder?

hustbaer

Naja, versteh mein "anscheinend langsam" bitte nicht Aussage über die Performance vom CE. Es ist nur die einzige Interpretation von dem was du schreibst, die mir schlüssig erscheint.

Ich habe mit SQL CE wie gesagt noch keine Erfahrungen, aber ich hatte - von dem was man so darüber liest - immer den Eindruck, dass er eher recht schnell sein soll.

Versuch vielleicht wirklich mal dasselbe mit der JET Engine oder noch besser mit SQL Server Express zu machen. Vielleich ist deine Maschine ja auch einfach viel langsamer, als das was ich gewohnt bin. Wenn du das auf einem Atom laufen hast, könnte die Performance unter Umständen "ganz normal" sein.

EXDW

wie lange dauert denn das stament wenn du es direkt im sql management studio laufen laesst ?

Hey, im studio selber ist das ganze auch net schneller.. ja meine Maschine is auch rel. schwach. (3ghz 1GB ram) Was mir augefallen ist, wenn ich die gleiche abfrage zweimal hintereinander starte, ist sie beim 2ten mal 1000m la schneller?? Werden die daten wohl irgendwie noch gecached??