mysql建数据库排序规则选什么（观文一览其正确排序规则）
MySQL在创建数据库时，需要设置数据库的字符集和排序规则，如图所示：
我觉得这里有必要解释下字符集和排序规则这两个概念。
字符集
说到字符集，需要先提下字符、字符集和字符编码这几个词的含义。
字符(Character)是各种文字和符号的总称，包括各国家文字、标点符号、图形符号、数字等。字符集(Character set)是多个字符的集合，字符集种类较多，每个字符集包含的字符个数不同，常见字符集名称：ASCII字符集、GB2312字符集、BIG5字符集、 GB18030字符集、Unicode字符集等。字符编码是把字符集中的字符编码为特定的二进制数，以便在计算机中存储。编码方式一般就是对二维表的横纵坐标进行变换的算法。一般都比较简单，直接把横纵坐标拼一起就完事了。后来随着字符集的不断扩大，为了节省存储空间，才出现了各种各样的算法。
字符集和字符编码一般都是成对出现的，如ASCII、IOS-8859-1、GB2312、GBK，都是即表示了字符集又表示了对应的字符编码，以后统称为编码。Unicode比较特殊，后面细说。
在MySQL中需要注意的utf8和utf8mb4这两种字符集的区别，utf-8编码格式我们经常会碰到，但是这里的utf8却不是指utf-8这种编码格式，那么又为啥会出现utf8mb4这种字符集呢？
据说MySQL一开始没有utf8mb4这个字符集，因为utf8只支持每个字符最多三个字节，而真正的UTF-8是每个字符最多四个字节，这就造成UTF-8编码下的一些字符无法保存到数据库中，为了修复这个bug而出现了utf8mb4这种字符集。
三个字节的UTF-8最大能编码的Unicode字符是0xFFFF，也就是Unicode中的基本多文平面（BMP）。也就是说，任何不在基本多文平面的Unicode字符，都无法使用MySQL原有的utf8字符集存储。这些不在BMP中的字符包括哪些呢？最常见的就是Emoji表情（Emoji是一种特殊的Unicode编码，常见于ios和android手机上），和一些不常用的汉字，以及任何新增的Unicode字符等等。
转载处
如果要在MySQL中保存4字节长度的UTF-8字符，就需要使用utf8mb4编码，但是要注意只有5.5.3版本以后的MySQL才支持（查看版本命令： select version()）。为了获取更好的兼容性，建议使用utf8mb4而非utf8. 对于CHAR类型数据，utf8mb4会多消耗一些空间，但根据 MySQL官方建议，可以使用VARCHAR替代CHAR。
扩展：char是一种固定长度的类型，varchar则是一种可变长度的类型（因为char长度固定，方便程序的存储与查找，所以char类型存取速度优于varchar，即以空间换效率）
排序规则
MySQL中常用的排序规则(这里以utf8字符集为例)主要有：utf8_general_ci、utf8_general_cs、utf8_unicode_ci等。
这里需要注意下ci和cs的区别:
ci的完整英文是&’Case Insensitive&’, 即“大小写不敏感”，a和A会在字符判断中会被当做一样的;cs的完整英文是‘Case Sensitive’，即“大小写敏感”，a 和 A 会有区分；
比如下面这个查询：
# 假设数据库中SC_Teacher表存在一条数据，其中TeacherName字段的值为 "A"select * from SC_Teacher where TeacherName = 'a' -- 如果数据库使用的是utf8_general_ci排序规则, 下面的查询是可以查询到这条数据-- 如果数据库使用的是utf8_general_cs排序规则, 下面的查询是查询不到这条数据正因为这个性质，导致utf8_general_ci的查询速度比utf8_general_cs快，(纯属个人推测，没有实际依据)
utf8_general_ci： 查询时不区分大小写匹配utf8_general_cs： 查询时区分大小写匹配utf8_bin： 字符串每个字符串用二进制数据编译存储。 区分大小写，而且可以存二进制的内容，与utf8_general_cs一样，区分大小写utf8_unicode_ci ： 和utf8_general_ci一样，不区分大小写
当前utf8_general_ci校对规则仅部分支持Unicode校对规则算法。一些字符还是不能支持。并且，不能完全支持组合的记号。这主要影响越南和俄罗斯的一些少数民族语言，如：Udmurt、Tatar、Bashkir和Mari。
utf8_general_ci的最主要的特色是支持扩展，即当把一个字母看作与其它字母组合相等时。例如，在德语和一些其它语言中‘?’等于‘ss’。
utf8_general_ci是一个遗留的校对规则，不支持扩展。它仅能够在字符之间进行逐个比较。这意味着utf8_general_ci校对规则进行的比较速度很快，但是与使用utf8_general_ci的校对规则相比，比较正确性较差）。
例如，使用utf8_general_ci和utf8_unicode_ci两种 校对规则下面的比较相等：
? = A ? = O ü = U
两种校对规则之间的区别是，对于utf8_general_ci下面的等式成立：
? = s
但是，对于utf8_unicode_ci下面等式成立：
? = ss
对于一种语言仅当使用utf8_unicode_ci排序做的不好时，才执行与具体语言相关的utf8字符集 校对规则。例如，对于德语和法语，utf8_unicode_ci工作的很好，因此不再需要为这两种语言创建特殊的utf8校对规则。
utf8_general_ci也适用与德语和法语，除了‘?’等于‘s’，而不是‘ss’之外。如果你的应用能够接受这些，那么应该使用utf8_general_ci，因为它速度快。否则，使用utf8_unicode_ci，因为它比较准确。
转载处
简短总结
utf8_unicode_ci和utf8_general_ci对中、英文来说没有实质的差别。utf8_general_ci校对速度快，但准确度稍差。utf8_unicode_ci准确度高，但校对速度稍慢。
如果你的应用有德语、法语或者俄语，请一定使用utf8_unicode_ci。一般用utf8_general_ci就够了，到现在也没发现问题。