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

故事源于最近boss在review script的时候提到了Data compression, 我查了一下，别人的介绍几乎都是

ALTER TABLE dbo.Table REBUILD WITH (DATA_COMPRESSION = PAGE);

但是boss却只是在Clustered Index（一般是primary key）上面做了data compression. 我还以为对表和对clustered index做data compression是两回事，而boss只是估计只在index上面做compression。而事实上，他们其实是一回事。查了一下，别人说是一样的。http://dba.stackexchange.com/questions/49757/clustered-index-compression-vs-table-compression-are-they-the-same-thing

测试一下，创建一张表

对clustered index加个data compression page.
验证一下
Drop掉primary key，对表进行row data compression，再试一次。


结论是，两者是一样的效果。其实也可以通过SSMS右键查看属性确认。

都说index越多，insert的语句越慢。无图无真相。

那么执行下面的query，你就能够看到第一个query cost是80%，第二个query cost是20%。

附上其他JOIN的关系图

周四要给team做presentation，topic是关于bug report的。上周五匆匆赶着写完了PPT，自己还小得意了一把。至少，这个算是工作一年来的小心得了。回到正题吧！