MySQL varchar存储、字符集、排序规则、索引长度

由于历史原因，MySQL刚开始设计的时候，"天真的"认为使用3个字节就足够存储字符串了，因此将UTF-8进行阉割然而遇到复杂的汉字或者emoji表情等4字节的宽字符的时候，存储就会出现异常，因此在版本5.7.3开始引入utf8mb4，其表示为most bytes 4，即最多占用4个字节。

utf8mb4_unicode_ci是基于官方的Unicode规则进行排序和压缩，其算法相对负责，对于大部分的语言和字符集排序有着很高的准确率而uft8mb4_general_ci可以理解为一种为了提升速度的简化版Unicode规则，但由于它不完全遵循Unicode规则，在使用某种特定语言或者字符集时，会出现非预期的结果。

例:

总结:

UTF-8编码的字符可以是1-4个字节，但是在MySQL中最大只能存储3个字节。

在版本5.5开始引入innodb_large_prefix，其默认值为off，索引的前缀最大限制为767个字节；若值为on时(版本5.7.7开始作为默认值)，最大限制为3072个字节。

总结:

在后期版本 innodb_large_prefix 将会被逐渐废弃并移除。从版本8.0开始，索引长度限制由表字段(row format)决定，若为DYNAMIC或COMPRESSED时，限制值为3072；为REDUNDANT或COMPACT时，限制值为767。且row_format=dynamic时，长度3072是基于innodb_page_size=16KB，随着innodb_page_size的值按比例增减，其索引前缀长度也响应减小，如若为8KB时，长度为1536，因此在限制索引长度时，需根据使用的MySQL版本以及相应的参数进行配置决定。

mysql>CREATE TABLE `tb` (

-> `a` varchar(255) DEFAULT NULL,

-> `b` varchar(255) DEFAULT NULL,

-> `c` varchar(255) DEFAULT NULL,

-> `d` varchar(255) DEFAULT NULL,

-> `e` varchar(255) DEFAULT NULL,

-> KEY `a` (`a`,`b`,`c`,`d`,`e`)

->) ENGINE=InnoDB DEFAULT CHARSET=utf8

ERROR 1071 (42000): Specified key was too longmax key length is 3072 bytes

可以看到，由于每个字段占用255*3, 因此这个索引的大小是3825>3072，报错。

为什么3072

我们知道InnoDB一个page的默认大小是16k。由于是Btree组织，要求叶子节点上一个page至少要包含两条记录（否则就退化链表了）。

所以一个记录最多不能超过8k。

又由于InnoDB的聚簇索引结构，一个二级索引要包含主键索引，因此每个单个索引不能超过4k （极端情况，pk和某个二级索引都达到这个限制）。

由于需要预留和辅助空间，扣掉后不能超过3500，取个“整数”就是(1024*3)。

单列索引限制

上面有提到单列索引限制767，起因是256×3-1。这个3是字符最大占用空间（utf8）。但是在5.5以后，开始支持4个字节的uutf8。255×4>767, 于是增加了一个参数叫做 innodb_large_prefix。

这个参数默认值是OFF。当改为ON时，允许列索引最大达到3072。

可以看到默认行为是建表成功，报一个warning，并且将长度阶段为255。

注意要生效需要加row_format=compressed或者dynamic 。

如果确实需要在单个很大的列上创建索引，或者需要在多个很大的列上创建联合索引，而又超过了索引的长度限制，解决办法是在建索引时限制索引prefix的大小：

例如：create index yarn_app_result_i4 on yarn_app_result (flow_exec_id(100), another_column(50))

这样，在创建索引时就会限制使用的每个列的最大长度。如上的例子中，在创建联合索引时，最多使用列flow_exec_id中前100个字符创建索引，最多使用another_column中前

50个字符创建索引。这样子，就可以避免索引长度过大的问题。

最后，我想说一句。我们在设计数据库时，最好不要在一个可能包含很长字符串的列上创建索引，尤其是当这个列中的字符串都很长时。如果在这类列上创建了索引，那么在创建索引时以及根据索引查询时，都会浪费很多时间在计算和存储上。有经验的设计人员应该不会这样设计数据库。

---