2012-03-28 13 views
1

Ich habe eine Multi-Tenant-Datenbank, die abhängig von dem Mandanten, der abgefragt wird, eine sehr unterschiedliche Anzahl von Zeilen zurückgibt. In letzter Zeit erleben wir ein Parameter-Sniffing-Problem, bei dem Entity Framework (EF) -Abfragen, die für einen Mandanten (TenantID = 1) ausgeführt werden, viel länger dauern als die gleiche Abfrage für einen anderen Mandanten (TenantID = 2). Ich habe einige Nachforschungen angestellt und festgestellt, dass EF keine Abfragehinweise unterstützt (siehe this question), die es mir erlauben würden, die Abfrage jedes Mal neu zu kompilieren. Jetzt frage ich mich, ob ich die Sql-Abfrage abfangen kann, die von EF generiert wird, und manuell "OPTION (OPTIMIZE FOR UNKNOWN)" anhängt, bevor es ausgeführt wird. Ist das möglich? Ist EF Pluggable, so dass ich die generierte Sql modifizieren kann, bevor sie ausgeführt wird? Gibt es Beispiele dafür?Kann ich den von Entity Framework generierten SQL-Code vor der Ausführung ändern?

Antwort

1

Haben Sie versucht, das Problem zu umgehen? Sie können in der Lage sein EF zu zwingen, keine param zu verwenden, zB:

var q = Context.Tenants.Where(t => t.TenantID == tenantId); 

... eine param verwenden, aber:

var r = Context.Tenants.Where(t => t.TenantID == 1); 

... nicht, und ich werde wette das:

var s = Context.Tenants.Where("it.TenantID = 1"); 

... wird auch nicht.

+0

Danke für Ihren Vorschlag. Leider ist das Erstellen von SQL-Abfragen im laufenden Betrieb (obwohl indirekt) aufgrund des hohen Risikos von SQL-Injection-Angriffen als schlechte Praxis anzusehen. Parametrisierte SQL ist der beste und einfachste Ansatz, um die SQL-Injektion aus Ihrer Anwendung herauszuhalten. – Mike

+1

Nun, deshalb verwendet die EF standardmäßig Parameter. Die Injektion ist jedoch nur ein Risiko, wenn Sie Ihre Eingaben nicht bereinigen. In dem speziellen Fall, den Sie geben, erlauben Sie, dass nur ganzzahlige Eingaben das Risiko einer Injektion eliminieren (wenn auch nicht das Risiko direkter Objektreferenzen, aber Params werden Sie auch davor nicht schützen ...). –

+0

Und wenn Sie Fortify-Scans verwenden, ist es nicht schlau genug zu wissen, dass Sie Ihre Eingaben bereinigt haben, bevor Sie SQL generieren. ;) –