请简述设置mysql数据库字符集的规则

字符集：罗列所有图形字符的一张大表。

排序规则：定义各个图形字符之间的大小比较规则，比如：是否区分大小写，区分全角和半角等。在软件使用中，一般我们只指定字符编码即可，因为确定了字符编码字符集自然就确定了。但是在数据库类软件中，我们除了要指定编码规则，还需要指定排序规则，因为，数据库是要提供模糊匹配、排序显示功能的。sql可以查看mysql支持的字符集编码和排序规则，其中每个字符集编码都有一个默认的排序规则。

我们的业务只存近一段时间的数据，因此有大量表需要清理 历史 数据，目前使用的delete清理数据，存在以下问题。为避免同时支持大量delete，我们的清理任务只在低峰期串行执行，导致任务过多时需要排队，甚至失败的情况；数据清理使用delete语句，表数据量较大时，对数据库造成很大压力；即使我们删除了旧数据，已删除的数据仍占据存储空间，底层数据文件并没有立刻变小，以至于形成数据空洞。

查看MySQL官方文档时，发现了分区表，因此基于官方文档总结一下。

MySQL逻辑上为一个表，物理上存储在多个文件中，这是 MySQL 支持的功能（5.1 开始）, 8.0 版本只 InnoDB 和 NDB 支持分区表。

优点：

缺点：

根据分区表键值的范围把数据存储到表的不同分区中，适用于以时间或日期作为分区类型，方便数据清理。

小提示：

1.当插入数据分区不存在时会报错：Table has no partition for value xxx

2.Range类型分区字段必须是数值，时间类型可用函数转换为数值；

3.分区字段列值可以为null，所有为null的数据将存在最小的分区中；

按分区键取值的列表进行分区，每一行数据须找到对应的分区列表，否则数据插入失败

小提示：

根据指定分区表达式的整数值以及分区数进行数据划分(mod函数)

小提示：

按键分区类似于按哈希分区，只是哈希分区使用用户定义的表达式，用于键分区的哈希函数由 MySQL 服务器提供。NDB 集群为此使用 MD5() 对于使用其他存储引擎的表，服务器使用自己的内部哈希函数。

小提示：

子分区(subpartitioning)也称为复合分区(composite partitioning) ，是已分区表中每个分区的进一步划分

小提示：

小提示：

最左原则顾名思义就是从最左边开始匹配的原则，mysql会一直向右匹配直到遇到范围查询(>、<、between、like)就停止匹配，索引可以任意顺序，mysql的查询优化器会帮你优化成索引可以识别的形式，其针对的是组合索引（又名联合索引）。

假设我们现在对A、B、C三个字段建立组合索引，来剖析什么时候会用到索引。

A=nickName, B=groupId, C=sign。

首先来看下我的表结构和索引如图1-2，在这里就不作过多赘述。

我先来介绍下图3中sql在expalin执行计划后得一些参数。

id： 为选择标识符。

select_type： 表示查询的类型，SIMPLE表示简单的select,没有union和子查询。

table： 输出结果集的表。

partitions： 匹配的分区。

type： 表示表的连接类型，range是指给定范围内的检索，比如 in(xx, xx) 或者 between。该类最好的时候是const（即表示为通过索引一次就找到了），最差的时候是all（需要遍历全表）。

possible_keys： 表示查询时，可能使用的索引。（显示可能应用在这张表中的索引，不一定能应用到。）

key： 表示实际使用的索引。

key_len： 索引字段的长度。

ref： 列与索引的比较。

rows： 找到所需的记录所需要读取的行数。

filtered： 按表条件过滤的行百分比。

Extra： 执行情况的描述和说明。

由图3的key字段看出A、B、C下，我们使用上了nickName_id_sign联合索引，rows字段看出，读取了1行。

那我们来看看B、C、A与C、B、A呢？

图4-5看出B、C、A与C、B、A也用到了索引，为什么呢？

这是因为当客户端把SQL语句传送到服务器后，服务器进程会对该语句进行解析。这个解析的工作是在服务器端所进行的，解析动作又可分为很多小动作。其中最重要的一步就是确定最佳执行计划。服务器进程会根据一定的规则，对这条语句进行优化。（在执行计划开始之前会有一步查询转换，如：视图合并、子查询解嵌套、谓语前推及物化视图重写查询等。【此处不理解可以忽略，大概可以理解为优化器寻找最低成本的执行计划】）。最终确定可能的最低成本的执行计划。当服务器进程的优化器确定这条查询语句的最佳执行计划后， 就会将这条SQL语句与执行计划保存到数据高速缓存，提高SQL语句处理效率。

在mysql中会使用Index Merge intersection algorithm算法来调整条件子句顺序(可以理解为上面所表述的 寻找最低成本的执行计划 )，详情请看 官方文档 。

由图6可以看出A、B组合也使用到了索引，看到type值为ref（非唯一性索引扫描，返回匹配某个单独值的所有行，本质上也是一种索引访问，它返回所有匹配某个单独值的行，它可能会找到多个符合条件的行，所以他应该属于查找和扫描的混合体。），再看rows，为40条，比A、B、C下略多，但还好，可以接受。

由图7可以看出A、C组合也使用到了索引，可以看到key_len索引中使用的字节数比A、B、C与A、B下小得多，再看rows，为七万多条， filtered 的过滤条件仅为百分之十，这是因为A、B、C组合索引覆盖了（A）、（A，B）、（A，B，C）三个索引 点击查看官方文档 ，而A、C组合用到了A索引，我们来看图8只有A条件nickName下与图7的rows参数都一致。filtered参数不一致是因为where的后置条件决定其过滤比例的。

图9可看出B、C组合下没有用到索引，type类型为ALL遍历整表去寻找记录， possible_keys与key 都为空，rows几乎为全表记录。这是因为组合索引的最左匹配原则，mysql会根据A来确定下一步的搜索方向，当没有A时，就只能去全记录去寻找。

有什么问题请留言，大家一起探讨学习