Zitat von
Valle:
Das weiß ich...
Zitat von
Valle:
LIKE ist generell sehr langsam...Besonders ein LIKE mit Wildcards ist sehr langsam
Das geht aus deinem Beitrag so nicht hervor. Denn wieso ist ein LIKE "(generell) sehr langsam", wenn es doch -soweit es geht- vorhanden Indexe benutzt? Hinterher behaupten:"Das weiss ich doch" kann Jeder.
(Los! schmunzel du nun auch mal!)
Zitat von
Valle:
Zitat von
alzaimar:
...Aber ob ich da dann noch ein 'REPLACE' rüber jage, macht den Kohl auch nicht fett.
Das kommt auf die Menge an.
Nein. Ein Replace arbeitet mit (so gut wie) konstantem Overhead pro Record und ist im Vergleich zur restlichen Performance eher vernachlässigbar. (Overhead ca. 2-3%, gemessen über 1Mio Recs).
Zitat von
Valle:
Ich konnte ja nicht wissen, ... und wie oft das aufgerufen wird.
Doch?
Ein mal pro Record?
Zitat:
Ich bin auch der Meinung, es ist nie falsch, auf so Sachen aufmerksam zu machen.
Das stimmt. Ich habe es auch nicht negiert, sondern nur präzisiert und einige deiner Behauptungen in Frage gestellt bzw.
imho korrigiert.
Zitat:
Ich hoffe du hast mitbekommen, dass er die 32k erst erwähnte, ... Aber Hauptsache ... unterstellen
Nun nimm doch nicht alles so persönlich. Ich unterstelle doch Nichts, aber wenn es so rüberkam: Entschuldigung.
Du hast pauschale Aussagen gemacht, die so einfach nicht korrekt waren. Das es "besonders bei schwachen Server zum Exitus kommt", weil eine
Query mit LIKE abgesetzt wird(was 'generell sehr langsam' ist
) kann man auch nicht unkommentiert stehen lassen, denn das ist auch zu pauschal. Denn auch ein 8xCPU-Server mit 20GHZ und 1TB
RAM geht bei idiotischen Queries in die Knie.
Meine Anmerkung: "Erst probieren, dann warnen" zielte auf deine pauschalen und nicht verifizierten Aussagen. Hättest Du erst den REPLACE-Overhead gemessen, und dein Wissen über die Verwendung von Indexen bei LIKE-Operatoren verwendet, müsste dein Beitrag eigentlich anders aussehen.
Zitat:
Mein nächster Post wäre gewesen, er sollte es doch mal testen bei den 32k.
Klar, hinterher weiss man es immer besser.
Aber eins kann man stehen lassen:
Zitat von
Valle:
Daher besser die Daten direkt mit "%" abspeichern.
Da fällt mir noch etwas ein: Du möchtest einen String über sehr viele Suchpattern jagen? Da gibt es Algorithmen, die sich auf soetwas spezialisiert haben. Stichwort:
Multiple Pattern Matching Hat nix mit
SQL zu tun, muss es auch nicht, denn ein
SQL-Server ist keine Patternsuchmaschine.