utf8mb4 -- UTF-8 Unicode和utf8 -- UTF-8 Unicode区别的整理

        MySQL在5.5.3之后增加了这个utf8mb4的编码，mb4就是most bytes 4的意思，专门用来兼容四字节的unicode。好在utf8mb4是utf8的超集，除了将编码改为utf8mb4外不需要做其他转换。当然，为了节省空间，一般情况下使用utf8也就够了。

        既然utf8应付日常使用完全没有问题，那为什么还要使用utf8mb4呢? 低版本的MySQL支持的utf8编码，最大字符长度为 3 字节，如果遇到 4 字节的字符就会出现错误了。三个字节的 UTF-8 最大能编码的 Unicode 字符是 0xFFFF，也就是 Unicode 中的基本多文平面（BMP）。也就是说，任何不在基本多文平面的 Unicode字符，都无法使用MySQL原有的 utf8 字符集存储。到http://blog.csdn.net/leelyliu/article/details/52879685看unicode编码区从1 ~ 126就属于传统utf8区,当然utf8mb4也兼容这个区,126行以下就是utf8mb4扩充区,什么时候你需要存储那些字符,你才用utf8mb4,否则只是浪费空间。  

那么utf8mb4比utf8多了什么的呢?

多了emoji编码支持.

如果实际用途上来看,可以给要用到emoji的库或者说表,设置utf8mb4.

比如评论要支持emoji可以用到.

建议普通表使用utf8 如果这个表需要支持emoji就使用utf8mb4

       排序规则选择常用的有utf8_general_ci , utf8_unicode_ci

       utf8_unicode_ci   是基于标准的Unicode来排序和比较，能够在各种语言之间精确排序 , 为了能够处理特殊字符的情况，实现了略微复杂的排序算法。所以  utf8_unicode_ci   的准确性比较好 , 但是性能相对比较低。

       utf8_general_ci  没有实现Unicode排序规则，在遇到某些特殊语言或字符是，排序结果可能不是所期望的。比如Unicode把ß、Œ当成ss和OE来看；而general会把它们当成s、e，再如ÀÁÅåāă各自都与 A 相等。在比较和排序的时候更快 ，所以utf8_general_ci  的准确性较低 ， 但是性能比较好。通常情况下 utf8_general_ci的准确性就够我们用的了。

       索引长度，从utf8转utf8mb4，容易引起索引键超长错误，InnoDB有单个索引最大字节数 768 的限制，而字段定义的是能存储的字符数，比如 VARCHAR(200) 代表能够存200个汉字，索引定义是字符集类型最大长度算的，超过768后抛出异常