HoneyHoney

本来想查查varchar和nvarchar在存储上面的区别的，结果走远了。。。

书上说过，nvarchar可以存储unicode data，但是每个字符需要两个字节。varchar则只需要一个字节。对于英文字符，varchar足够了，但是系统做大了，一般都会i18n（国际化），所以需要用nvarchar。网上很多人都推荐nvarchar，至少这样可以减少各种转换之间的痛苦。

1. 那在存储上，到底有什么特殊的地方么？


创建如上table，结果如下。
可以看到，char和varchar不支持中文，显示为两个问号，即乱码了。下面会说为什么会乱码。
那具体的存储上面的区别呢？

执行如下命令，可以发现，char(50)是固定长度，varchar(50)是根据数据的实际长度，nvarchar(50)则是varchar(50)的两倍。中文依旧乱码，除了nvarchar.



2. 如果进行row data compression呢？数据长度则被很好的压缩了。

3. 为什么会乱码呢？因为在插入的时候，系统会自动把字符转换成为column所对应的类型(以及Collation)。然而，'中国'会被转换成为not defined（因为在对应的code page上面找不到），即0x3f3f。而0x3f就是问号，所以查询出来的就是问号。如果只知道问号，是没有办法查到原来的数据的，即垃圾数据。
4. 那如何确保中文能够正确存进去呢？有两种方法，一是用nvarchar或者nchar，二是用正确的collation。如下图，ItemName3是nvarchar, ItemName4是varchar with collation Chinese_PRC_CI_AS。


5. 那ItemName3和ItemName4在存储上面有什么不同呢？用上面的命令可以发现，ItemName3存储的是2d4e fd56，对应的是unicode table上面的4e2d 56fd。ItemName4存储的是d6d0 b9fa，对应的是gb2312上面的d6d0 b9fa。所以，varchar是支持中文的，只要你的collation是支持中文的(database, table, column level都可以设置collation）。





http://unicode-table.com/en/#4E2D
http://ash.jp/code/cn/gb2312tbl.htm