MySQL优化四（优化表结构）

Posted 2020-09-16 赵弘添

mysql优化四（优化表）

昨晚吃吃喝喝的太多，熬夜到凌晨二点。今天头发杂乱，脸庞憔悴，像是吸毒了。下午去买衣服，肚子一看大了不少。奈何女朋友还没有一个，就已经发福了。管不住口，迈不开腿。

一、优化表结构

1.尽量将表字段定义为NOT NULL约束，这时由于在MySQL中含有空值的列很难进行查询优化，NULL值会使索引以及索引的统计信息变得很复杂，可以使用0或者空字符串来代替。

2.可以使用enum、set 等符合数据类型。对于只包含特定类型的字段。不过在工作过程中一般就使用tinyint 来表示了。

3.数值型字段的比较比字符串的比较效率高得多，字段类型尽量使用最小、最简单的数据类型。IP地址可以使用int类型。

二、表拆分

1、垂直拆分

垂直拆分按照字段进行拆分，其实就是把组成一行的多个列分开放到不同的表中，这些表具有不同的结构，拆分后的表具有更少的列，例如用户表中的一些字段可能经常访问，可以把这些字段放进一张表里。另外一些不经常使用的信息就可以放进另外一张表里。插入的时候使用事务，也可以保证两表的数据一致。缺点也很明显，由于拆分出来的两张表存在1：1的关系，需要使用冗余字段，而且需要join操作，我们在使用的时候可以分别取两次，这样的来说既可以避免join操作，又可以提高效率。

2、水平拆分

水平拆分按照行进行拆分，常见的就是分库分表。以用户表为例，可以取用户ID,然后使用php的十进制转换16进制的方法 dechex,截取其中的第一个字符，将用户均匀的分配进这 0-9 、a-f 这16个表中。查找的时候也按照这种规则，又快又方便。当然类似的规则很多，也可以使用求余法，按照余数将数据分发进不同的表中。有些表业务关联比较强，那么可以使用按时间划分的。以我公司的某业务为例，每天都要新建一张表。这种业务类型就是需要高速插入，但是对于查询的效率不太关心。表越大，插入数据所需要索引维护的时间也就越长。

三、分区

分区这个概念，我第一次在实践中看到是在去年，数据中心的表按照时间一个月分成一个区。我从这些表中读取数据，然后继续做后续的业务处理。一般来说在主业务中很少使用这种分区概念，使用分区是大数据处理后的产物。比如系统用户的注册推广等等，会产生海量的日志，当然也可以按照时间去建立多张表，但在实际操作中，就发生过一次运维人员忘记切换表，导致数据报错的紧急事件。可见分区适用于日志记录，查询少，一般用于后台的数据报表分析。对于这些数据汇总需求，需要很多日志表去做数据聚合，我们能够容忍1s到2s的延迟，只要数据准确能够满足需求就可以。

MySQL主要支持4种模式的分区：range分区、list预定义列表分区，hash 分区，key键值分区。后几种没有看到数据中心的同事用过，可能是操作不方便，应用不广泛，所以就暂且不讲了。

-- 创建表
create table testpar
(
    f_userid int unsigned not null default 0,
    f_date datetime
)engine=innodb,charset=utf8;

-- 分区
alter table testpar  partition by range columns(f_date) (
    partition p0 values less than (‘2017-01-31‘),
    partition p2 values less than (‘2017-02-20‘)
);

-- 查看表结构
mysql> show create table testpar\G
*************************** 1. row ***************************
       Table: testpar
Create Table: CREATE TABLE `testpar` (
  `f_userid` int(10) unsigned NOT NULL DEFAULT ‘0‘,
  `f_date` datetime DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8
/*!50500 PARTITION BY RANGE  COLUMNS(f_date)
(PARTITION p0 VALUES LESS THAN (‘2017-01-31‘) ENGINE = InnoDB,
 PARTITION p2 VALUES LESS THAN (‘2017-02-20‘) ENGINE = InnoDB) */
1 row in set (0.00 sec)