nvarchar的使用有多糟

我們的軟件部署在出現性能問題的客戶端，他們聘請了SQL顧問來查看數據庫並查看其瓶頸所在。nvarchar的使用有多糟

顧問發現的其中一件事是我們很多的陳述轉換爲nvarchar。經過一番調查，我發現它是PreparedStatement這樣做。

給你舉個例子：

PreparedStatement query = connection.prepareStatement("SELECT * FROM sys.tables WHERE" 
     + " name LIKE ?"); 
query.setString(1, "%%");

變爲

declare @p1 int 
set @p1=1 
exec sp_prepexec @p1 output,N'@P0 nvarchar(4000)',N'SELECT * FROM sys.tables WHERE name LIKE @P0  ',N'%%' 
select @p1

在另一方面即席executeQuery方法只是通過

ResultSet rs = connection.createStatement().executeQuery("SELECT * FROM sys.tables WHERE name LIKE '%%'");

成爲

發送SQL

我試圖解決的是這個實際上有多糟糕。準備好的語句被用在我們的應用程序中，因爲它們的使用比特殊查詢更有效率（如果執行多次）。

此外，我不能看到微軟的人會把他們的驅動程序，他們知道會導致性能問題的東西。

這是我們應該真正關注的東西，還是尋找沒有任何問題的顧問？

2012-06-29 Tim Sparg

pepared語句強制查詢成爲參數化查詢（這是件好事），而即席查詢可能會或可能不會被SQL引擎自動參數化。總之，這不是主要的表現。

但是，從設計的角度來看，你是否應該使用參數化存儲過程總是會有很多爭論（不是必需的性能之一）。我認爲大多數DBA（也可能是數據庫顧問）更喜歡存儲過程，因爲它們使用傳統數據庫管理工具（以及提供安全優勢，以及默認包括參數化）更容易調試。

2012-06-29 17:17:36

準備好的語句比專門查詢有更多的優化選項，從安全角度來看通常會更好（沒有按設計進行SQL注入）。

nvarchar使用情況通常來自非功能性需求。如果您希望您的應用程序支持任何Unicode字符，這在目前非常常見，您需要它。如果這在需求中，請不要更改它。

我認爲LIKE查詢是罪魁禍首，你應該看看你的後端數據庫中的全文索引功能。該查詢看起來非常簡單，它是LIKE的'％'查詢，可以掃描每個字段中的字符序列。

2014-09-06 06:47:23

回答