Vor kurzem habe ich eine langsame Abfrage wie folgt überwacht:
Wählen Sie Delete_flag, delete_timefrom d_orderInfo wobei (orderid ist nicht null und orderid = n'xxxx ')
Es gibt einen Index von OrderID in der Tabelle d_orderInfo, aber das Feld OrderID ist vom Typ Varchar.
Da das Entwicklungsframework myBatis automatisch den WHERE -Zustand generiert und den Parametertyp nicht angibt, wird der Parameter des String -Typs automatisch zu NVarchar (4000) in SQLServer. Was schwierig ist, ist, dass es in Ordnung ist, wenn Sie den Parametertyp nicht angeben, aber Sie auch automatisch eine SARG-Bedingung wie OrderID hinzufügen, und der Ausführungsplan wird wie folgt:
-----------------------------------------------------------------------------------------------------------------------------------------------------
Wenn es keine OrderID gibt, ist keine Nullbedingung, ist der Ausführungsplan wie folgt:
Da der Parametertyp nvarchar eine höhere Priorität hat als der Indexfeldtyp Varchar, kann er nicht direkt konvertiert werden, aber der SQLServer -Optimierer umwandelt ihn schließlich in einen Bereichswert, und die endgültige Abfrage für gleiches Vorzeichen ähnelt einer kleinen Bereichsabfrage.
Sie können aus den detaillierten Informationen von Index suchen:
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Wenn die Parametertypen übereinstimmen, ist der Ausführungsplan wie erwartet (obwohl nicht enthalten ist, gibt es immer noch eine wichtige Suche):
Natürlich hoffte ich endlich wie folgt: wie folgt:
Wählen Sie Delete_flag, delete_timefrom d_orderInfo wobei orderid = 'xxxx' '
Der Ausführungsplan wird natürlich so sein:
Aber ich weiß einfach nicht, worauf der Entwicklungsmeister am Ende ändern kann ...
Die Lösung des Entwicklungsmeisters: Konfigurieren Sie die Verbindungszeichenfolge:
sendStringParametersasunicode = false
PostScript:
Standardmäßig werden Zeichendaten in Java als Unicode verarbeitet. Java -String -Objekte repräsentieren Unicode -Zeichendaten. Bei JDBC -Treibern sind die einzigen Dinge, die dieser Regel nicht befolgen können, die ASCII -Stream -Getter- und Setter -Methoden, die Sonderfälle sind, da die von diesen Methoden verwendeten Byte -Streams die implizite Annahme einer einzelnen bekannten Code -Seite (ASCII) tragen.
Zusätzlich stellt der JDBC -Treiber die SendStringParametersasunicode -Verbindungs -Zeichenfolge -Eigenschaft bereit. Diese Eigenschaft kann verwendet werden, um vordefinierte Parameter für Zeichendaten anstelle von Unicode festzulegen.
Als Leistungsverbesserung kann der String-Parameter in einem Nicht-Unicode-Format an SQL Server übergeben werden, indem die SendStringParametersAsunicode-Verbindungs-Zeichenfolge-Eigenschaft festgelegt wird. Die Standardeinstellung von sendStringParametersasunicode ist "wahr", was bedeutet, dass der String -Parameter als Unicode gesendet wird.
Wenn SendStringParametersasunicode auf "False" eingestellt ist, werden alle String -Parameter in der Verbindung mit der Datenbank -Standardkollation an den Server gesendet.
Siehe:
http://d.hatena.ne.jp/gnarl/20110706/1309945379
https://technet.microsoft.com/zh-cn/library/ms378857(sql.90).aspx
https://technet.microsoft.com/zh-cn/library/ms378988(v=sql.90).aspx