MySQL高级篇01【字符集、SQL规范和sql

1. 字符集操作
- 1.1 修改MySQL5.7字符集
- - 1. 修改步骤
  - 2.已有库/表字符集的变更
- 1.2 字符集级别分类
- - 1. 服务器级别
  - 2. 数据库级别
  - 3. 表级别
  - 4. 列级别
  - 5. 小结
- 1.3 字符集的比较规则（了解）
- - 1. utf8 与 utf8mb4
  - 2. 比较规则
  - 3. 字符集与比较规则常用操作
- 1.4 请求到响应过程中字符集的变化
2. SQL大小写规范
- 2.1 Windows与Linux平台区别
- 2.2 Linux下大小写规则设置
- 2.3 SQL编写建议
3. sql_mode的合理设置
- 3.1 宽松模式 vs 严格模式
- 3.2 模式查看与设置

1. 字符集操作

1.1 修改MySQL5.7字符集

1. 修改步骤

在MySQL8.0之前，默认字符集为 latin1 ，utf8 字符集指向的是 utf8mb3 。
从MySQL8.0开始，默认字符集为 utf8mb4。

查看默认使用的字符集

show variables like 'character%';
# 或者
show variables like '%char%';

MySQL8.0执行结果展示

mysql> show variables like '%char%';
+--------------------------+--------------------------------+
| Variable_name            | Value                          |
+--------------------------+--------------------------------+
| character_set_client     | utf8mb4                        |
| character_set_connection | utf8mb4                        |
| character_set_database   | utf8mb4                        |
| character_set_filesystem | binary                         |
| character_set_results    | utf8mb4                        |
| character_set_server     | utf8mb4                        |
| character_set_system     | utf8mb3                        |
| character_sets_dir       | /usr/share/mysql-8.0/charsets/ |
+--------------------------+--------------------------------+
8 rows in set (0.08 sec)

MySQL5.7执行结果展示

mysql> show variables like '%char%';
+--------------------------+----------------------------+
| Variable_name            | Value                      |
+--------------------------+----------------------------+
| character_set_client     | utf8                       |
| character_set_connection | utf8                       |
| character_set_database   | latin1                     |
| character_set_filesystem | binary                     |
| character_set_results    | utf8                       |
| character_set_server     | latin1                     |
| character_set_system     | utf8                       |
| character_sets_dir       | /usr/share/mysql/charsets/ |
+--------------------------+----------------------------+
8 rows in set (0.05 sec)

修改字符集

vim /etc/my.cnf

在MySQL5.7或之前的版本中，在文件最后加上中文字符集配置，MySQL8.0无需配置：

character_set_server=utf8

重启MySQL服务

systemctl restart mysqld

注意：参数修改仅对修改后新增加的数据库和表有效，对已创建的无效。

2.已有库/表字符集的变更

修改已创建数据库的字符集

ALTER DATABASE dbtest1 CHARACTER SET 'utf8';

修改已创建数据表的字符集

ALTER TABLE t_emp CONVERT TO CHARACTER SET 'utf8';

注意：但是原有的数据如果是用非’utf8’编码的话，数据本身编码不会发生改变。已有数据需要导出或删除，然后重新插入。

1.2 字符集级别分类

MySQL有4个级别的字符集和比较规则，分别是：

服务器级别
数据库级别
表级别
列级别

执行如下SQL语句：

mysql> show variables like '%char%';
+--------------------------+--------------------------------+
| Variable_name            | Value                          |
+--------------------------+--------------------------------+
| character_set_client     | utf8mb4                        |
| character_set_connection | utf8mb4                        |
| character_set_database   | utf8mb4                        |
| character_set_filesystem | binary                         |
| character_set_results    | utf8mb4                        |
| character_set_server     | utf8mb4                        |
| character_set_system     | utf8mb3                        |
| character_sets_dir       | /usr/share/mysql-8.0/charsets/ |
+--------------------------+--------------------------------+
8 rows in set (0.08 sec)

character_set_server：服务器级别的字符集
character_set_database：当前数据库的字符集
character_set_client：服务器解码请求时使用的字符集
character_set_connection：服务器处理请求时会把请求字符串从character_set_client转为character_set_connection
character_set_results：服务器向客户端返回数据时使用的字符集

1. 服务器级别

character_set_server ：服务器级别的字符集。

可以在启动服务器程序时通过启动选项，或者在服务器程序运行过程中，使用 SET 语句修改这两个变量的值。比如我们可以在配置文件中这样写：

[server]
character_set_server=gbk # 默认字符集
collation_server=gbk_chinese_ci #对应的默认的比较规则

当服务器启动的时候读取这个配置文件后这两个系统变量的值便修改了。

2. 数据库级别

character_set_database ：当前数据库的字符集
在创建和修改数据库的时候可以指定该数据库的字符集和比较规则，具体语法如下：

CREATE DATABASE 数据库名[[DEFAULT] CHARACTER SET 字符集名称][[DEFAULT] COLLATE 比较规则名称];ALTER DATABASE 数据库名[[DEFAULT] CHARACTER SET 字符集名称][[DEFAULT] COLLATE 比较规则名称];

3. 表级别

我们也可以在创建和修改表的时候指定表的字符集和比较规则，语法如下：

CREATE TABLE 表名 (列的信息)[[DEFAULT] CHARACTER SET 字符集名称][COLLATE 比较规则名称]]ALTER TABLE 表名[[DEFAULT] CHARACTER SET 字符集名称][COLLATE 比较规则名称]

如果创建和修改表的语句中没有指明字符集和比较规则，将使用该表所在数据库的字符集和比较规则作为该表的字符集和比较规则（向上查找字符集和比较规则）。

4. 列级别

对于存储字符串的列，同一个表中的不同的列也可以有不同的字符集和比较规则。在创建和修改列定义的时候可以指定该列的字符集和比较规则，语法如下：

CREATE TABLE 表名(列名 字符串类型 [CHARACTER SET 字符集名称] [COLLATE 比较规则名称],其他列...
);
ALTER TABLE 表名 MODIFY 列名 字符串类型 [CHARACTER SET 字符集名称] [COLLATE 比较规则名称];

对于某个列来说，如果在创建和修改的语句中没有指明字符集和比较规则，将使用该列所在表的字符集和比较规则作为该列的字符集和比较规则（向上查找字符集和比较规则）。

提示
在转换列的字符集时需要注意，如果转换前列中存储的数据不能用转换后的字符集进行表示会发生错误。比方说原先列使用的字符集是utf8，列中存储了一些汉字，现在把列的字符集转换为ascii的话就会出错，因为ascii字符集并不能表示汉字字符。

5. 小结

四个级别字符集和比较规则的联系如下：

如果 创建或修改列 时没有显式的指定字符集和比较规则，则该列 默认用表的 字符集和比较规则
如果 创建表 时没有显式的指定字符集和比较规则，则该表 默认用数据库的 字符集和比较规则
如果 创建数据库时 没有显式的指定字符集和比较规则，则该数据库 默认用服务器的 字符集和比较规则

1.3 字符集的比较规则（了解）

1. utf8 与 utf8mb4

utf8 字符集表示一个字符需要使用1～4个字节，但是我们常用的一些字符使用1～3个字节就可以表示了。而字符集表示一个字符所用的最大字节长度，在某些方面会影响系统的存储和性能，所以设计MySQL的设计者偷偷的定义了两个概念：

utf8mb3 ：阉割过的 utf8 字符集，只使用1～3个字节表示字符。
utf8mb4 ：正宗的 utf8 字符集，使用1～4个字节表示字符。

2. 比较规则

上表中，MySQL版本一共支持41种字符集，其中的 Default collation 列表示这种字符集中一种默认的比较规则，里面包含着该比较规则主要作用于哪种语言，比如 utf8_polish_ci 表示以波兰语的规则比较， utf8_spanish_ci 是以西班牙语的规则比较，utf8_general_ci 是一种通用的比较规则。后缀表示该比较规则是否区分语言中的重音、大小写。具体如下：

后缀	英文释义	描述
`_ai`	`accent insensitive`	不区分重音
`_as`	`accent sensitive`	区分重音
`_ci`	`case insensitive`	不区分大小写
`_cs`	`case sensitive`	区分大小写
`_bin`	`binary`	以二进制方式比较

3. 字符集与比较规则常用操作

常用操作1：

#查看GBK字符集的比较规则
SHOW COLLATION LIKE 'gbk%';#查看UTF-8字符集的比较规则
SHOW COLLATION LIKE 'utf8%';

常用操作2：

#查看服务器的字符集和比较规则
SHOW VARIABLES LIKE '%_server';#查看数据库的字符集和比较规则
SHOW VARIABLES LIKE '%_database';#查看具体数据库的字符集
SHOW CREATE DATABASE dbtest1;#修改具体数据库的字符集
ALTER DATABASE dbtest1 DEFAULT CHARACTER SET 'utf8' COLLATE 'utf8_general_ci';

常用操作3：

#查看表的字符集
show create table employees;#查看表的比较规则
show table status from atguigudb like 'employees';#修改表的字符集和比较规则
ALTER TABLE emp1 DEFAULT CHARACTER SET 'utf8' COLLATE 'utf8_general_ci';

1.4 请求到响应过程中字符集的变化

系统变量	描述
`character_set_client`	服务器解码请求时使用的字符集
`character_set_connection`	服务器处理请求时会把请求字符串从`character_set_client` 转为 `character_set_connection`
`character_set_results`	服务器向客户端返回数据时使用的字符集

现在假设我们客户端发送的请求是下边这个字符串：

SELECT * FROM t WHERE s = '我';

为了方便大家理解这个过程，我们只分析字符'我' 在这个过程中字符集的转换。

现在看一下在请求从发送到结果返回过程中字符集的变化：

客户端发送请求所使用的字符集

一般情况下客户端所使用的字符集和当前操作系统一致，不同操作系统使用的字符集可能不一样，如下：
- Unix 系统使用的是 utf8
- Windows 使用的是 gbk
当客户端使用的是 utf8 字符集，字符 '我' 在发送给服务器的请求中的字节形式就是：0xE68891
服务器接收到客户端发送来的请求其实是一串二进制的字节，它会认为这串字节采用的字符集是character_set_client ，然后把这串字节转换为character_set_connection 字符集编码的字符。
由于我的计算机上 character_set_client 的值是 utf8 ，首先会按照 utf8 字符集对字节串 0xE68891 进行解码，得到的字符串就是 '我' ，然后按照 character_set_connection 代表的字符集，也就是 gbk 进行编码，得到的结果就是字节串 0xCED2 。
因为表 t 的列 col 采用的是 gbk 字符集，与 character_set_connection 一致，所以直接到列中找字节值为 0xCED2 的记录，最后找到了一条记录。

提示：
如果某个列使用的字符集和character_set_connection 代表的字符集不一致的话，还需要进行一次字符集转换。

上一步骤找到的记录中的 col 列其实是一个字节串 0xCED2 ， col 列是采用 gbk 进行编码的，所以首先会将这个字节串使用 gbk 进行解码，得到字符串 '我' ，然后再把这个字符串使用character_set_results 代表的字符集，也就是 utf8 进行编码，得到了新的字节串：0xE68891 ，然后发送给客户端。
由于客户端是用的字符集是 utf8 ，所以可以顺利的将 0xE68891 解释成字符 我，从而显示到我
们的显示器上，所以我们人类也读懂了返回的结果。

总结如图：

注意：

请求时：当 客户端操作系统请求字符集 与 character_set_client字符集 一致时，才能正确解码请求字符。
响应时：当 客户端操作系统响应字符集 与 character_set_results字符集 一致，才能正确解码响应字符。
character_set_connection 与其他两个不一致时，不会影响请求和响应的编码解码，依然能正确编码解码。

2. SQL大小写规范

2.1 Windows与Linux平台区别

Windows系统默认大小写不敏感，但是 Linux系统是大小写敏感的。
通过如下命令查看：

SHOW VARIABLES LIKE '%lower_case_table_names%'

Windows系统下：

mysql> SHOW VARIABLES LIKE '%lower_case_table_names%';
+------------------------+-------+
| Variable_name          | Value |
+------------------------+-------+
| lower_case_table_names | 1     |
+------------------------+-------+
1 row in set, 1 warning (0.00 sec)

Linux系统下：

mysql> SHOW VARIABLES LIKE '%lower_case_table_names%';
+------------------------+-------+
| Variable_name          | Value |
+------------------------+-------+
| lower_case_table_names | 0     |
+------------------------+-------+
1 row in set (0.00 sec)

lower_case_table_names参数值的设置：
- 默认为0，大小写敏感。
- 设置1，大小写不敏感。创建的表，数据库都是以小写形式存放在磁盘上，对于sql语句都是转换为小写对表和数据库进行查找。
- 设置2，创建的表和数据库依据语句上格式存放，凡是查找都是转换为小写进行。
两个平台上SQL大小写的区别具体来说：

MySQL在Linux下数据库名、表名、列名、别名大小写规则是这样的：
1、数据库名、表名、表的别名、变量名是严格区分大小写的；
2、关键字、函数名称在 SQL 中不区分大小写；
3、列名（或字段名）与列的别名（或字段别名）在所有的情况下均是忽略大小写的；

MySQL在Windows的环境下全部不区分大小写

2.2 Linux下大小写规则设置

当想设置为大小写不敏感时，要在my.cnf这个配置文件 [mysqld] 中加入lower_case_table_names=1 ，然后重启服务器。

但是要在重启数据库实例之前就需要将原来的数据库和表转换为小写，否则将找不到数据库名。
此参数适用于MySQL5.7。在MySQL 8下禁止在重新启动 MySQL 服务时将 lower_case_table_names 设置成不同于初始化 MySQL 服务时设置的 lower_case_table_names 值。如果非要将MySQL8设置为大小写不敏感，具体步骤为：
```
1、停止MySQL服务
2、删除数据目录，即删除 /var/lib/mysql 目录
3、在MySQL配置文件（ /etc/my.cnf ）中添加 lower_case_table_names=1
4、启动MySQL服务
```

2.3 SQL编写建议

关键字和函数名称全部大写；
数据库名、表名、表别名、字段名、字段别名等全部小写；
SQL 语句必须以分号结尾。

数据库名、表名和字段名在 Linux MySQL 环境下是区分大小写的，因此建议你统一这些字段的命名规则，比如全部采用小写的方式。

虽然关键字和函数名称在 SQL 中不区分大小写，也就是如果小写的话同样可以执行。但是同时将关键词和函数名称全部大写，以便于区分数据库名、表名、字段名。

3. sql_mode的合理设置

3.1 宽松模式 vs 严格模式

宽松模式：

如果设置的是宽松模式，那么我们在插入数据的时候，即便是给了一个错误的数据，也可能会被接受，并且不报错。

例如：在插入字符时，超过了char(5)长度，则不会报错，直接截取前5个字符，后面的丢弃。

应用场景：数据迁移时可以使用，使用后则无需对业务sql进行大量修改。

严格模式：

在生产等环境中，我们必须采用的是严格模式，进而开发、测试环境的数据库也必须要设置，这样在开发测试阶段就可以发现问题。

开发经验： MySQL虽然提供了这些严格的校验，但是在开发中建议在项目程序级别中就将这些校验完成，虽然写起来麻烦了点，但是在数据迁移时，方便很多！

严格模式存在的问题：

若设置模式中包含了NO_ZERO_DATE ，那么MySQL数据库不允许插入零日期，插入零日期会抛出错误而不是警告。例如，表中含字段TIMESTAMP列（如果未声明为NULL或显示DEFAULT子句）将自动分配 DEFAULT '0000-00-00 00:00:00'（零时间戳），这显然是不满足sql_mode中的NO_ZERO_DATE而报错。

3.2 模式查看与设置

查看当前的sql_mode

select @@session.sql_mode
select @@global.sql_mode#或者show variables like 'sql_mode';

临时设置方式：设置当前窗口中设置sql_mode

SET GLOBAL sql_mode = 'modes...'; #全局
SET SESSION sql_mode = 'modes...'; #当前会话

举例：

#改为严格模式。此方法只在当前会话中生效，关闭当前会话就不生效了。
set SESSION sql_mode='STRICT_TRANS_TABLES';
#改为严格模式。此方法在当前服务中生效，重启MySQL服务后失效。
set GLOBAL sql_mode='STRICT_TRANS_TABLES';

永久设置方式：在/etc/my.cnf中配置sql_mode
在my.cnf文件(windows系统是my.ini文件)，新增：

[mysqld]
sql_mode=ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR
_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION

然后重启MySQL。

当然生产环境上是禁止重启MySQL服务的，所以采用临时设置方式 + 永久设置方式来解决线上的问题，那么即便是有一天真的重启了MySQL服务，也会永久生效了。