Unicode压缩在R2中有帮助

SQL Server 2008 R2中的一个新特性是Unicode压缩。Unicode支持世界上所有的国际字符集，包括中文、日文、韩文和台湾文。代价是unicode每个字符需要2字节，而标准字符数据类型每个字符只使用一个字节。这是存储空间的两倍。R2试图节省大部分开销，尤其是西部字母的开销。当我和女儿以及她二年级的同学们谈论我的日本之旅时，他们惊讶地得知日本字母表中有超过2000个汉字。他们刚刚开始对付我们的26个。如果你曾经需要重新设计一个应用程序来支持日本的本地化，你就会知道这需要花费多少时间和精力。如果您的应用程序是数据驱动的，并且您使用过像nchar和nvarchar这样的SQL Server Unicode数据类型，那么本地化就相对简单了。然而，国际支持的成本是支持Unicode及其双字节字符集所需存储空间的两倍。即使是西方字符也要占用2个字节。 Not now. If you use the Data Compression feature of SQL Server 2008, then R2 will automatically add Unicode compression for you when new rows are added. If you rebuild the object, all rows will include Unicode Compression. That counts for Row-level compression or Page-level Compression. If most of your unicode data is based on western alphabets, the storage savings can be close to 50%. If most of your data is, for instance, Japanese then your savings will only be around 15%. But even then there are storage savings. As we saw with the Data Compression in SQL Server 2008, there is an extra CPU overhead of around 10% for the decompression but assuming a savings of I/O based on less data pages to load into memory, you may be looking at a net gain in performance too. Obviously, this depends on the data and the level of compression but should be evident during testing. The "Manage Compression" wizard in SSMS helps you estimate your storage savings. The wizard will tell you how much space will be saved if row or page compression is enabled. Just right-click your table, choose Storage then Manage Compression to start the wizard. You can then do "what-if" analysis using the Calculate button. Data Compression is one of my favorite features in SQL Server 2008 because, surprisingly, there does not appear to be a downside. Flick a switch to save storage and improve performance. Who can't like that? And it gets better with SQL Server 2008 R2. (Actual results may vary...) cheers Brian