我正在遷移大型Web服務以兼容國際字符。它是一個Tomcat/Spring MVC/SQL Server堆棧。遷移本身是相對直接的，我們在Tomcat中做了一些設置更改，強制在響應中默認使用UTF-8，更改了一些Java代碼以使用編碼，並將一些VARCHAR列遷移到NVARCHAR，然後將健康劑量的單元/功能測試。Unicode和性能
我的團隊中的另一個人現在要進行負載測試，以確保沒有任何更改對系統性能產生不利影響。上述這種轉變的各個組成部分並沒有真正暗示任何性能改變，坦率地說，根據我有限的知識，我認爲這不是完全必要的。無論如何，我打算這麼做，但是我的問題就是這樣 - 在這樣的遷移中可能會出現哪些性能問題？對於可能會改變系統性能的不同字符編碼，是否有特定的內容？
我能想到的唯一的事情就是繁重的字符串比較和排序等任何想法？
我只有這段趣聞：
在我，我們遇到了在數據庫（ASCII）文本字段正在對在查詢unicode字符串相匹配的問題，以前的公司。這導致sql server切換到表掃描而不是通常的索引，因爲它無法證明字符串總是可以轉換爲ascii。這對我們來說是一個重大的表現。
是的 - 我們也遇到過這個問題。如果你使用Hibernate，這尤其令人討厭，因爲在當前版本中，你必須將所有的Unicode或所有的ASCII都設置爲列。 – dfb 2011-06-08 16:34:54
@spinning_plate：你知道的很好。除非您製作非常大的測試數據庫，否則這通常難以進行壓力測試。 – 2011-06-08 17:26:28
字符編碼，只要它做得對，應該不是問題。 Unicode很複雜，但你不會考慮這一點。其他人已經做到了。所有你需要考慮的是你不會以無意義的方式轉換任意字符串。
然而，你會看到，所有的字符串數據將佔用兩倍的空間。這確實會影響SQL Server用來創建執行計劃的啓發式方法，並且索引可能會發生變化，但是，如果您沒有真正的大型數據集，我不會擔心這一點。
你應該考慮升級到SQL Server 2008 R2，因爲它提供Unicode Compression：
的Unicode壓縮在SQL Server 2008 R2使用的 的Unicode（SCSU）的 標準的壓縮方式的實現算法來壓縮 存儲在行 或頁面壓縮對象中的Unicode值。對於這些 壓縮對象，Unicode 對nchar（n） 和nvarchar（n）列自動進行壓縮。 SQL 服務器數據庫引擎將統一碼 數據存儲爲2個字節，而不管區域設置如何。 這被稱爲UCS-2編碼。對於 的一些區域設置，執行 SCSU壓縮SQL Server 2008 R2 可以節省高達50％的存儲空間 空間。
你會遇到的最大困難是數據類型優先規則。因爲NVARCHAR的優先級高於VARCHAR，所以任何混合這兩者的表達式都將被強制爲NVARCHAR。實際上，這意味着列A和列B之間的連接條件是之前在兩個VARCHAR列之間並且導致索引查找，現在它將在CAST(A as NVARCHAR)和B之間（考慮我們只將B更改爲NVARCHAR），並且這不再是SARGable（將導致表掃描）。這個問題可以出現在連接，WHERE子句，參數類型和許多其他地方。它需要仔細考慮，結果的性能下降是巨大的（全掃描與尋找）。
感謝所有的答案，我隨機選擇一個接受，因爲它們都一樣好 – dfb 2011-06-13 16:32:13