SQL Abfrageplan

Habe im Moment nur noch ein Problem, welches mir nicht aufgeht:

Scenario 1:
--Reads:17889, CPU: 406, Duration: 407
SELECT TOP 1 NULL FROM "XXX$Artikel" WITH (READUNCOMMITTED)
WHERE (("Nummer" LIKE '%[1¹][3³]G0[2²]0[2²][3³][2²]460%'))

--> Warum macht der SQL hier einen Index Scan? Verwendet wird
der index "Aktiv M (bool), Nummer(Prim.Key))"
Hier müsste doch eigentlich der $0 Index verwendet werden oder?
Was kann man hier machen?


Scenario 2:
--Reads:168017, CPU: 7328, Duration: 7402
declare @P1 varchar(20)
set @P1 = '%[2²][2²]9[2²]567%'
SELECT * FROM "XXX$Geb_ Verkaufsrechnungskopf" WHERE ((CAST("Auftragsnummer" AS VARCHAR(255)) LIKE @P1)) ORDER BY "Nummer" OPTION (FAST 10)

--> Hier sehe ich, dass die ORDER BY Clausel falsch ist, jedoch würde ein Index existieren (Auftragsnummer,Nummer). Der SQL macht einen Clustered Index Scan ... warum ???
Wenn ich hier die ORDER BY (manuell) ändere (Auftragsnummer,Nummer), dann sind die Kosten minimal höher, jedoch die Abfrage doppelt so schnell. Kann das sein, dass der Abfrageoptimierer einen Fehler macht? (Anh. der Kosten ist's ja schon korrekt, jedoch ineffizient).


Wartungspläne:
1x/Woche: Rebuild
1x/Tag: Reorganize

Hat hier jemand eine Idee? Kann das nicht nachvollziehen!

Also zuerst was die "Kosten" im Ausführungsplan angeht: Hier handelt es sich nicht um Zeiteinheitn etc. sondern um die Gewichtung der einzelnen Teiloperationen zueinander, also z.B. wieviel Prozent der Zeit für einen "Non-Clustered Index Seek" im Verhältnis zum "Bookmark Lookup" und "Sort" verbraucht wird. Die echten Kosten in Form von Zeit oder logischen/physikalischen Zugriffen erhält man im Profiler (Reads, Writes, CPU, Duration).

Was Deine Abfragen angeht, so wird in beiden Fällen immer mit hoher Wahrscheinlichkeit ein "Scan" durchgeführt, da der Suchausdruck "Wildcards" (%) enthält. Insbesondere ein "%" am Anfang verhindert, dass SQL Server die korrekte "Root Node" eines Indexes als "Einsprungspunkt" findet - egal ob ein passender Index existiert oder nicht.

Ein ORDER BY dürfte an diesem Verhalten eigentlich nix ändern, lediglich der Aufwand für ein etwaiges Umsortieren sollte beeinflusst werden ...
Ist das ORDER BY extrem "widersprüchlich" (= hoher Sortieraufwand) zum eigentlich optimaleren Index, so kann dies zur Folge haben, dass eben ein sub-optimaler Index gezogen. Ein besseres ORDER BY gibt dem SQL Server die Chance einen besseren Index zu ziehen, auch wenn dieser u.U. aufgrund von Wildcards gescannt wird ...

Hallo Jörg

Danke für deine Hilfe.

Das Problem mit dem Wildcard (%) ist mir bekannt, darum versuchte ich diese Abfrage ohne dieses auszuführen, jedoch ohne Erfolg.
SELECT -> FILTER -> COMPUTE SCALAR -> CI SCAN

Könnte es sein, dass es Probleme gibt, wenn die Felder als SQLVARIANT definiert sind?

Könnte es sein, dass es Probleme gibt, wenn die Felder als SQLVARIANT definiert sind?

Das hab' ich noch nicht untersucht ...

... hast du ev. eine andere Idee, was da falsch laufen könnte?

Hmmm ... wenn man von den "Wildcards" nicht loskommt und die betroffenen Felder schon indiziert sind, dann fürchte ich, fällt mir im Moment nix mehr dazu ein ... sorry ...