Vor gut zwei Monaten hatte ich über unterschiedliche Ergebnismengen bei prepared vs. non-prepared Statements berichtet. Zwischenzeitlich kam ein weiteres Phänomen dazu, was an das erste Phänomen erinnert:
Seit mehreren Monaten fallen uns immer mal wieder prepared Queries auf, deren Performance deutlich (Faktor 10 bis 100) schlechter ist, als das entsprechende non-prepared Queries. Alle Queries hatten gemeinsam, dass in einer wichtigen Bedingung eine VARCHAR-Spalte verwendet wird, auf der es einen Index gibt. Ein Blick auf die Ausführungspläne zeigte, dass die non-prepared Query einen performanten Index-Lookup durchführte, die prepared Query jedoch einen langsamen Index-Scan.
Als Ursache stellte sich der als Unicode-Wert übergebene Parameter der Bedingung auf der VARCHAR-Spalte (also keine Unicode-Werte) heraus. In so einem Fall scheint der SQL-Server – warum auch immer – keinen Lookup im Index machen zu wollen.
Lösungen:
- Ein Umstieg auf NVARCHAR-Spalten. Das ist unser bevorzugtes, mittelfristiges Ziel aber wie immer im Leben leider nicht sofort umsetzbar.
- Den JDBC-Treiber auf Non-Unicode-Parameterübergabe umschalten (sofern möglich).