2016-04-19 22 views
0

Ich habe Schwierigkeiten, eine Abfrage hier zu verstehen. Meine Abfrage gibt letztendlich eine Ergebnismenge in einem Bericht zurück, in der Sie eine Person im Parameter angeben können, um ihre Daten anzuzeigen. Ich verbinde meine Dimension-Tabelle mit meiner Employee-Tabelle, um den Namen aus der Employee-Tabelle zurückzugeben. Es sieht so etwas wie dieserAbfrage hängt mit Parameter in WHERE-Klausel

Declare @PM varchar(30) 
Set @PM = 'John Smith' 

SELECT....FullName, EmployeeID, .... 
FROM... 
Inner Join EmployeesT on emp.EmployeeNumber = DimP.PersonID 
WHERE FullName in (@PM) 

Hinweis: Meine Employee-Tabelle ist in nvarchar und Dimension ist varchar aber ich glaube nicht, dass Fragen wie die nach wie vor kommen funktionieren.

Jetzt habe ich oben einen Parameter zum Testen gesetzt.

Hier ist mein Problem: Wenn ich die WHERE-Klausel zu WHERE DimP.PersonID IN ('12345') sagen, dauert meine Abfrage 3 Sekunden zu laufen. Wenn ich die Abfrage in WHERE FullName in (@PM) ändere dauert die Abfrage für immer; Es hängt und läuft für 5+ Menuette. Hat jemand ein ähnliches Problem erlebt?

Die Ergebnismenge erzeugt die richtigen Daten mit mehreren „Menschen“ und ich möchte dies testen, indem eine Person Angabe keine ID, aber wenn ich die Parameter auf den Namen der Abfrage hängt ..

+0

Das Leistungsproblem hängt mehr mit der Tabellenstruktur und den Indizes zusammen. Auch wenn Sie nur einen Namen eingeben, warum setzen Sie nicht einfach "WHERE FullName = @ PM"? – momar

+0

Ich habe das versucht und hatte das gleiche Problem. Es wurde gelöst, indem die folgende CASE-Anweisung unten hinzugefügt wurde. Ich habe keine Ahnung, warum – Geo

+0

Ich bin mir nicht sicher, ob die case-Anweisung korrekt ist, da es nichts zurückzugeben scheint. Sie sollten wahrscheinlich die vollständige Abfrage in der Frage veröffentlichen. Darüber hinaus kann das Leistungsproblem das Ergebnis eines fehlerhaften Ausführungsplans sein. Siehe Diskussion hier: https://www.brentozar.com/archive/2014/06/tuning-stored-procedures-local-variables-problems/ – momar

Antwort

0

ändern Meine Mitarbeiter konnte dieses Problem zu lösen: sie verwendet WHERE emp.empNumber = (CASE WHEN emp.FullName IN (@PM))

:)

+2

War das die genaue Syntax, die sie verwendet hat, weil ziemlich sicher, dass es nur zum Fehler geht, wenn fügst du das hinzu ... es sei denn, das sind die gewünschten Ergebnisse? Schauen Sie sich [diesen Blog] (http://www.sqdoubleg.com/2016/03/03/fast-with-values-slow-with-variables/) für einen möglichen Grund für die Verlangsamung an. – Shaneis

+0

@Shaneis Die Abfrage sollte in weniger als 5 Sekunden ausgeführt werden. Die Verwendung von IN PM oder emp.empNumber = PM würde hängen bleiben und mehr als 5 Minuten dauern. Die Verwendung dieser Fallbeschreibung scheint das Problem gelöst zu haben. – Geo

+0

Lösen Sie das Problem, dass es über 5 Minuten dauert, um zu laufen? Ich habe keinen Zweifel, als das letzte Mal, dass ich überprüft habe, werden Fehler sofort zurückgegeben. Wenn dies Ihr Timing-Problem gelöst hat, ist das großartig! Aber die vollständige CASE-Syntax hat nicht, was Sie dort haben. 'CASE input_expression WENN DANN when_expression result_expression [... n] [ELSE else_result_expression] END' – Shaneis

0

Es Parameter Sniffing sein könnte. Es hängt am optimierten Ausführungsplan für einen anderen Parameterwert. Versuchen Sie, OPTIONEN (OPTIMIZE FÜR (@parm UNKNOWN)) am Ende Ihrer Abfrage zu verwenden.

Declare @PM varchar(30) 
Set @PM = 'John Smith' 

SELECT....FullName, EmployeeID, .... 
FROM... 
Inner Join EmployeesT on emp.EmployeeNumber = DimP.PersonID 
WHERE FullName in (@PM) 

OPTION (OPTIMIZE FOR (@PM UNKNOWN)) 
Verwandte Themen