在典型的SQL服務器性能優化實踐中，我們經常使用JDBC驅動程序來識別哪一位用戶使用的SQL服務器資源最多。使用JDBC驅動程序中的字符數據類型屬性轉換可以節省SQL服務器資源。

　　查詢語句對于常使用JDBC驅動程序的用戶來說并不陌生。

　　SELECT contact FROM tbl_Customers WHERE ID = @P0

　　這種查詢僅需要3毫秒的時間即可以得到結果，看起來并不是太慢。但在使用這個語句對SQL服務器進行查詢的時候，已經經歷了數百萬次計算，并且在這個過程中，將限制SQL其他程序運行對數據庫資源的使用。為了了解整個運行過程，讓我們看一下這個語句所牽扯到的SQL查詢計劃后臺的運行程序。您會發現，這個過程其實比想象的要復雜許多。（這里僅提供執行計劃中的最重要的一部分）：

　　Nested Loops(Inner Join, OUTER REFERENCES:([Expr1004],

　　|--Compute Scalar(DEFINE:(([Expr1004],[Expr1005],[Expr1003])=GetRangeThroughConvert([@P0)

　　| |--Constant Scan

　　|--Clustered Index Seek(OBJECT:([Prod].[dbo].[tbl_Customers]..[ID].. SEEK:( [ID] >
　　[Expr1008] AND [ID] < [Expr1009]),

　　WHERE:(CONVERT_IMPLICIT(nvarchar(255), [ID],0)=[@P0])

　　在整個查詢過程中，程序運行了嵌套循環。這是對一個文件的單一查找，為何SQL服務器在編譯查詢計劃是會使用嵌套循環程序而不是直接通過索引尋找相應的文件參數值？如果仔細分析一下上面的后臺運行程序，您會發現在上述程序語句中有一個隱形的嵌套循環語句：

　　CONVERT_IMPLICIT(nvarchar(255), [ID],0)

　　這個語句就是為什么SQL服務器會重復引用嵌套程序的原因所在。為了盡量減少客戶端Java本地字符串之間的轉換，Java程序是按照統一碼編寫的。這就使得用戶在使用JDBC驅動程序對SQL服務器進行查詢或操作時，所有的varchar()會在默認狀態下變為nvarchar()變量。而在SQL程序運行中nvarchar()變量的運行優先級高于varchar()變量。SQL服務器自身并不能將nvarchar()變量轉換為varchar()變量，所以執行兩種語句代碼之間的轉換時會發生一些錯誤。如@P0本身是varchar()變量，但鏈接傳送給SQL數據庫時會以nvarchar()變量的形式傳送。

　　那么，我們如何使得JDBC驅動程序停止這一轉換呢？在JDBC驅動程序屬性中有一個按照“統一碼字符串參數發送鏈接命令“（sendStringParametersAsUnicode）的選項。在默認狀態下，這個選項的選擇是，我們可以手動的將其改為否。這樣問題就得到了解決。@P0會按照varchar()變量進行發送，從而不再參與到嵌套循環查詢過程中。

　　如果用戶希望同時傳送varchar（）和nvarchar（）變量時，可以先將“統一碼字符串參數發送鏈接命令”的選項設置為否。另外增加保證nvarchar（）變量傳輸的語句：

　　pStmt.setObject(2,Id,Types.NVARCHAR);

　　在對鏈接字符串屬性進行修改后，整個過程運行的時間可以由3毫秒縮減為1.5毫秒。總工作量可以提高20%。沒想到吧，一個小小的設置可以帶來那么大的后臺運行變化