MYSQL中的COLLATE是什么?

3A网络
• 阅读 676

在mysql中执行show create table <tablename>指令,可以看到一张表的建表语句,example如下:

CREATE TABLE `table1` (
    `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
    `field1` text COLLATE utf8_unicode_ci NOT NULL COMMENT '字段1',
    `field2` varchar(128) COLLATE utf8_unicode_ci NOT NULL DEFAULT '' COMMENT '字段2',
    PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8_unicode_ci;

大部分字段我们都能看懂,但是今天要讨论的是COLLATE关键字。这个值后面对应的utf8_unicode_ci是什么意思呢?面试的时候用这个题目考一考DBA,应该可以难倒一大部分人。

COLLATE是用来做什么的?

使用phpmyadmin的开发可能会非常眼熟,因为其中的中文表头已经给出了答案:

MYSQL中的COLLATE是什么?

所谓utf8_unicode_ci,其实是用来排序的规则。对于mysql中那些字符类型的列,如VARCHARCHARTEXT类型的列,都需要有一个COLLATE类型来告知mysql如何对该列进行排序和比较。简而言之,COLLATE会影响到ORDER BY语句的顺序,会影响到WHERE条件中大于小于号筛选出来的结果,会影响**DISTINCT****GROUP BY****HAVING**语句的查询结果。另外,mysql建索引的时候,如果索引列是字符类型,也会影响索引创建,只不过这种影响我们感知不到。总之,凡是涉及到字符类型比较或排序的地方,都会和COLLATE有关

各种COLLATE的区别

COLLATE通常是和数据编码(CHARSET)相关的,一般来说每种CHARSET都有多种它所支持的COLLATE,并且每种CHARSET都指定一种COLLATE为默认值。例如Latin1编码的默认COLLATElatin1_swedish_ciGBK编码的默认COLLATEgbk_chinese_ciutf8mb4编码的默认值为utf8mb4_general_ci

这里顺便讲个题外话,mysql中有utf8utf8mb4两种编码,在mysql中请大家忘记**utf8**,永远使用**utf8mb4**。这是mysql的一个遗留问题,mysql中的utf8最多只能支持3bytes长度的字符编码,对于一些需要占据4bytes的文字,mysql的utf8就不支持了,要使用utf8mb4才行。

很多COLLATE都带有_ci字样,这是Case Insensitive的缩写,即大小写无关,也就是说"A"和"a"在排序和比较的时候是一视同仁的。selection * from table1 where field1="a"同样可以把field1为"A"的值选出来。与此同时,对于那些_cs后缀的COLLATE,则是Case Sensitive,即大小写敏感的。

在mysql中使用show collation指令可以查看到mysql所支持的所有COLLATE。以utf8mb4为例,该编码所支持的所有COLLATE如下图所示。

MYSQL中的COLLATE是什么?

mysql中和utf8mb4相关的所有COLLATE

图中我们能看到很多国家的语言自己的排序规则。在国内比较常用的是utf8mb4_general_ci(默认)、utf8mb4_unicode_ciutf8mb4_bin这三个。我们来探究一下这三个的区别:

首先utf8mb4_bin的比较方法其实就是直接将所有字符看作二进制串,然后从最高位往最低位比对。所以很显然它是区分大小写的。

utf8mb4_unicode_ciutf8mb4_general_ci对于中文和英文来说,其实是没有任何区别的。对于我们开发的国内使用的系统来说,随便选哪个都行。只是对于某些西方国家的字母来说,utf8mb4_unicode_ci会比utf8mb4_general_ci更符合他们的语言习惯一些,general是mysql一个比较老的标准了。例如,德语字母“ß”,在utf8mb4_unicode_ci中是等价于"ss"两个字母的(这是符合德国人习惯的做法),而在utf8mb4_general_ci中,它却和字母“s”等价。不过,这两种编码的那些微小的区别,对于正常的开发来说,很难感知到。本身我们也很少直接用文字字段去排序,退一步说,即使这个字母排错了一两个,真的能给系统带来灾难性后果么?从网上找的各种帖子讨论来说,更多人推荐使用utf8mb4_unicode_ci,但是对于使用了默认值的系统,也并没有非常排斥,并不认为有什么大问题。结论:推荐使用utf8mb4_unicode_ci,对于已经用了utf8mb4_general_ci的系统,也没有必要花时间改造。

另外需要注意的一点是,从mysql 8.0开始,mysql默认的CHARSET已经不再是Latin1了,改为了utf8mb4,并且默认的COLLATE也改为了utf8mb4_0900_ai_ciutf8mb4_0900_ai_ci大体上就是unicode的进一步细分,0900指代unicode比较算法的编号( Unicode Collation Algorithm version),ai表示accent insensitive(发音无关),例如e, è, é, ê 和 ë是一视同仁的。

COLLATE设置级别及其优先级

设置COLLATE可以在示例级别、库级别、表级别、列级别、以及SQL指定。实例级别的COLLATE设置就是mysql配置文件或启动指令中的collation_connection系统变量。

库级别设置COLLATE的语句如下:

CREATE DATABASE <db_name> DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

如果库级别没有设置CHARSETCOLLATE,则库级别默认的CHARSETCOLLATE使用实例级别的设置。在mysql8.0以下版本中,你如果什么都不修改,默认的CHARSETLatin1,默认的COLLATElatin1_swedish_ci。从mysql8.0开始,默认的CHARSET已经改为了utf8mb4,默认的COLLATE改为了utf8mb4_0900_ai_ci

表级别的COLLATE设置,则是在CREATE TABLE的时候加上相关设置语句,例如:

CREATE TABLE (

……

) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

如果表级别没有设置CHARSETCOLLATE,则表级别会继承库级别的CHARSETCOLLATE

列级别的设置,则在CREATE TABLE中声明列的时候指定,例如

CREATE TABLE (

`field1` VARCHAR(64) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci NOT NULL DEFAULT '',

……

) ……

如果列级别没有设置CHARSETCOLATE,则列级别会继承表级别的CHARSETCOLLATE

最后,你也可以在写SQL查询的时候显示声明COLLATE来覆盖任何库表列的COLLATE设置,不太常用,了解即可:

SELECT DISTINCT field1 COLLATE utf8mb4_general_ci FROM table1;
SELECT field1, field2 FROM table1 ORDER BY field1 COLLATE utf8mb4_unicode_ci;

如果全都显示设置了,那么优先级顺序是 SQL语句 > 列级别设置 > 表级别设置 > 库级别设置 > 实例级别设置。也就是说列上所指定的COLLATE可以覆盖表上指定的COLLATE,表上指定的COLLATE可以覆盖库级别的COLLATE。如果没有指定,则继承下一级的设置。即列上面没有指定COLLATE,则该列的COLLATE和表上设置的一样。

以上就是关于mysql的COLLATE相关知识。感兴趣的朋友可以在3A的服务器上部署一套相关的环境进行实验,不过,在系统设计中,我们还是要尽量避免让系统严重依赖中文字段的排序结果,在mysql的查询中也应该尽量避免使用中文做查询条件。

点赞
收藏
评论区
推荐文章
Wesley13 Wesley13
3年前
MySQL数据库优化技巧
MySQL优化三大方向①优化MySQL所在服务器内核(此优化一般由运维人员完成)。②对MySQL配置参数进行优化(my.cnf)此优化需要进行压力测试来进行参数调整。③对SQL语句以及表优化。MySQL参数优化1:MySQL默认的最大连接数为100,可以在mysql客户端使用以下命令查看mysql
Stella981 Stella981
3年前
Hive建表的Location问题
最近公司在使用Hive做项目测试,所以就在Hive上面建了一些表,做测试。使用建表语句后发现数据被自动覆盖了,现在了解到的情况是这样的。Hive中,表的Metadata信息全部存储在MySQL中。而存储在MySQL中的数据是没有校验过程的。也就是说,你可以创建一个逻辑错误的表,两个表指向同一个HDFS文件也是有可能的。所以,在使用CREA
Wesley13 Wesley13
3年前
Mysql重复数据去重保留一条数据
创建一张测试表createtablepoi(idbigint(20)NOTNULLAUTO_INCREMENTCOMMENT'id',poi_idbigint(20)NOTNULLCOMMENT'poi_id',PRIMARYKEY(id));
Wesley13 Wesley13
3年前
mysql字段默认值不生效的问题解决(上)
在项目中使用mybatis做为持久层框架,mysql数据库。项目上线前,DBA要求我们将每张数据库表中的字段都设置默认值和notnull。之前项目中有一些insert语句是将表中所有字段都列出来,然后把它做为一个通用的插入语句来使用。举个简单的例子:假如一张数据库表blog中有如下几个字段:id,title,content,author,除id外,每个字段
Stella981 Stella981
3年前
Explain(MySQL高级知识四)
前言:explain(执行计划),使用explain关键字可以模拟优化器执行sql查询语句,从而知道MySQL是如何处理sql语句。explain主要用于分析查询语句或表结构的性能瓶颈。注:本系列随笔如无特殊说明都MySQL版本都为5.7.22。1.explain的作用通过explainsql语句可以知道如下内容:①表的读取顺序。(
Wesley13 Wesley13
3年前
mysql中int、bigint、smallint 和 tinyint的区别与长度
通过创建一张表,来看看mysql中intbigintsmallint和tinyint的区别与长度1、在mysql命令行创建如下表CREATETABLEtest_int_1(int_idintNOTNULL,bigint_idbigintDEFAULTNULL,
Wesley13 Wesley13
3年前
mysql组合索引与字段顺序
很多时候,我们在mysql中创建了索引,但是某些查询还是很慢,根本就没有使用到索引!一般来说,可能是某些字段没有创建索引,或者是组合索引中字段的顺序与查询语句中字段的顺序不符。看下面的例子:假设有一张订单表(orders),包含order\_id和product\_id二个字段。一共有31条数据。符合下面语句的数据有5条。执行下面的s
3A网络 3A网络
2年前
输入的查询 SQL 语句,是如何执行的?
输入的查询SQL语句,是如何执行的?执行如下SQL,我们看到的只是输入一条语句,返回一个结果,却不知道这条语句在MySQL内部的执行过程。textselectfromwhereid'1';上图给出的是MySQL的基本架构示意图,从中你可以清楚地看到SQL语句在MySQL的各个功能模块中的执行过程。大体来说,MySQL可以分为
为什么mysql不推荐使用雪花ID作为主键
作者:毛辰飞背景在mysql中设计表的时候,mysql官方推荐不要使用uuid或者不连续不重复的雪花id(long形且唯一),而是推荐连续自增的主键id,官方的推荐是auto_increment,那么为什么不建议采用uuid,使用uuid究
京东云开发者 京东云开发者
1个月前
自增主键去哪了?---一次开发过程中的思考
前情提要:最近新接了一个需求,需要去创建两张表,其中有一张表需要根据业务id和业务类型建立唯一索引,对数据唯一性进行约束。因为涉及到业务嘛,表结构就进行缩略了表结构示例如下:CREATETABLEexampletable(idbigint(20)unsig