AND in SQL-Abfrage

[ChristianT]

Hallo Leute,
ich habe eine Datenbank im MS SQL Server 2022, die eine umfangreiche Tabelle, in derer es eine Volltext-Indizierte Spalte gibt, in welcher gesucht wird, enthält.
Die Abfrage 1 ist extrem schnell und bringt mir bei der Suche nach "spax*" das gewünschte Ergebnis.

Die Varianten 2 und 3, 4 sind sehr langsam und bringen mir das gleiche Ergebnis wie Variante 1, da die Abfrage "s*" natürlich auch in "spax*" enthalten ist.
Auch wenn ich das "spax*" und das "s*" vertausche bleibt es sehr langsam - siehe Variante 4.

Die "Bremse" ist natürlich die Abfrage nach "s*", weil es hierbei sehr viele Ergebnisse gibt.

Wenn der SQL-Server bei der linken Bedingung ("spax*") feststellt dass diese FALSE ergibt, dann sollte er ja gar nicht mehr die rechte Abfrage nach dem "AND" machen und somit sehr viel schneller sein.

Warum ist das so?
Gibt es eine Möglichkeit das zu unterbinden bzw. zu verbessern?

Ich kenne sowas zb. von Visual Basic-Programmiersprache, wo anstatt des Schlüsselwortes "AND" "ANDALSO" verwendet werden kann.


1) dauert unter einer Sekunde:
SELECT Tabelle where contains(Spalte, '"spax*"')

2) dauert ca. 20 Sekunden:
SELECT Tabelle where contains(Spalte, '"spax*" AND "s*"')

3) dauert ebenfalls ca. 20 Sekunden:
SELECT Tabelle where contains(Spalte, '"spax*"') AND contains(Spalte, '"s*"')

4) dauert ebenfalls ca. 20 Sekunden:
SELECT Tabelle where contains(Spalte, '"s*"') AND contains(Spalte, '"spax*"')


Vielen Dank im Voraus
Christian

 

[ukulele]

Ich habe leider noch keine Erfahrung mit Full Text Search und CONTAINS(). Du kannst im SSMS mit einem Schalter den tatsächlichen Ausführungsplan mit ausgeben lassen. Meist liefert der gute Hinweise darauf, was lange dauert. In dem Fall wird aber vermutlich CONTAINS genau ein Teil des Ausführungsplans sein, keine Ahnung. Einfach mal austesten und schauen, was dort steht.

 

[dabadepdu]

Ich denke es liegt an dem kurzen Suchwort, ein Volltextindex kann damit nicht viel anfangen, prinzipbedingt.

 

[ChristianT]

Ich denke es liegt an dem kurzen Suchwort, ein Volltextindex kann damit nicht viel anfangen, prinzipbedingt.

Ja genau und deshalb möchte ich die Reihenfolge für die Abfolge der mit "AND" verknüpften Bedingungen festlegen, was ja kein Problem ist.
Damit kommt immer der lange Suchbegriff als erstes. Wenn der lange Suchbegriff in der Tabelle nicht gefunden wird, dann sollte der SQL-Server nicht mehr weitere Bedingungen prüfen und mit dem nächsten Datensatz weitermachen, weil es ja am Ergebnis nichts mehr ändert.

Warum also alle "AND" Bedingungen prüfen, wenn schon eine FALSE ergibt.

 

[dabadepdu]

Ja genau und deshalb möchte ich die Reihenfolge für die Abfolge der mit "AND" verknüpften Bedingungen festlegen

Sorry, ich habs nicht geschnallt.
Aber es funktioniert wahrscheinlich anders.
"Die erste Bedingung ist schon false, deswegen brauch ich nicht mehr weitere Bedingungen zu prüfen" ist wahrscheinlich nicht die Herangehensweise.
Der Tipp von @ukulele ist schon richtig. Schau Dir den Ausführungsplan an.
Der Optimizer entscheidet unabhängig von einem Einzelergebnis in einem Datensatz, welche Menge er aufgrund der Conditions und passenden Indizes als erstes abfragt. Das hat erstmal nichts mit Einzelergebnissen zu tun. (Es sei denn es gibt Statistiken, die eine Vorausswahl erlauben)
Ein typisches Optimizervorgehen wäre wahrscheinlich "auf der Spalte hab ich einen Index, auf den anderen nicht, also mache ich diese Einschränkung zuerst". Wie das genau bei MSSQL Server in dieser Version ist, weiß ich nicht. Der Ausführungsplan gibt es aber an.

Trifft der Optimizer eine unerwartete Entscheidung, muss man herausfinden warum. Die Reihenfolge der Conditions zu ändern hilft wahrscheinlich nicht.

 

[ukulele]

Ein typisches Optimizervorgehen wäre wahrscheinlich "auf der Spalte hab ich einen Index, auf den anderen nicht, also mache ich diese Einschränkung zuerst". Wie das genau bei MSSQL Server in dieser Version ist, weiß ich nicht. Der Ausführungsplan gibt es aber an.

Trifft der Optimizer eine unerwartete Entscheidung, muss man herausfinden warum. Die Reihenfolge der Conditions zu ändern hilft wahrscheinlich nicht.

Definitiv, so würde ich das auch versuchen zu beschreiben. Der Optimizer in SQL eigentlich sehr gut, daher befasst man sich dann auch selten mit. Ich bin da auch nicht so der Profi, ich wäre mir aber auch sicher das die Reihenfolge im Statement keine Rolle spielt und vom Optimizer sowieso "optimiert" wird. In einem normalen INNER JOIN mit WHERE-Condition kann man das auch ganz gut nachstellen. Es ist eigentlich egal ob eine Bedingung in der Join Condition steht oder im WHERE-Teil, die Geschwindigkeit ändert sich nicht.

Bei einem so simplen Query gibt es ja auch nicht besonders viel Spielraum wo der Optimizer überhaupt was falsch machen könnte. Daher vermute ich die Besonderheit in den Volltext-Funktionalitäten.