MySQL数据库：表结构优化

数据库操作中最为耗时的操作就是 IO 处理，大部分数据库操作 90% 以上的时间都花在了 IO 读写上面。所以减少 IO 次数可以在很大程度上提高数据库操作的性能。

由于MySQL数据库是基于行存储的数据库，而数据库IO操作的时候是以 page 的方式，也就是说，如果我们每行记录所占用的空间量减小，就会使每个 page 中可存放的数据行数增大，那么每次 IO 可访问的行数也就增多了。反过来说，处理相同行数的数据，需要访问的 page 就会减少，也就是 IO 操作次数降低，直接提升性能。此外，由于我们的内存是有限的，增加每个page中存放的数据行数，就等于增加每个内存块的缓存数据量，同时还会提升内存换中数据命中的几率，也就是缓存命中率。我们无法改变数据库中需要存储的数据，但是我们可以在数据的存储方式方面做一些优化。

一、数据类型的选择：

下面关于字段类型的优化建议主要适用于记录条数较多，数据量较大的场景。但是精细化的数据类型可能带来维护成本的提高，过度优化也可能会带来其他的问题。

1、数字类型：

（1）非万不得已不要使用DOUBLE，不仅仅只是存储长度的问题，同时还会存在精确性的问题。

（2）固定精度的小数，也不建议使用DECIMAL，建议乘以固定倍数转换成整数存储，可以大大节省存储空间，且不会带来任何附加维护成本。

（3）对于整数的存储，在数据量较大的情况下，建议区分开 TINYINT / INT / BIGINT 的选择，因为三者所占用的存储空间也有很大的差别，能确定不会使用负数的字段，建议添加unsigned定义。当然，如果数据量较小的数据库，也可以不用严格区分三个整数类型。

（4）int类型只增主键字段=>4字节=>每个字节8位=>32位，在CPU加载一条指令的时候，4字节是和CPU寄存器的运算有关，如：64位，由于之前的系统一般都是32位的，所以在运算4字节的数据是刚好的，效率最高，而现今我们系统基本都是64位的时候，其实没有更好的利用好CPU运算，所以在设计表字段建议，使用8字节的主键bigint，而不是直接使用int来做主键。

2、字符类型：

（1）非万不得已不要使用 TEXT 数据类型，其处理方式决定了他的性能要低于char或者是varchar类型的处理。

（2）对于定长字段，建议使用 CHAR 类型，不定长字段尽量使用 VARCHAR，且设定适当的最大长度，而不是非常随意的给一个很大的最大长度限定，因为不同的长度范围，MySQL也会有不一样的存储处理。

char(n) 不管该字段是否存储数据，都占n个字符的存储空间；varchar 不存的时候不占空间，存多长数据就占多少空间，可以节省存储空间。

3、时间类型：

（1）尽量使用TIMESTAMP类型，因为其存储空间只需要 DATETIME 类型的一半。但是timestamp存储的数据所以被限制在了1970~2038年之内。

（2）对于只需要精确到某一天的数据类型，建议使用DATE类型，因为他的存储空间只需要3个字节，比TIMESTAMP还少。

4、ENUM & SET：

对于状态字段，可以尝试使用 ENUM 来存放，因为可以极大的降低存储空间，而且即使需要增加新的类型，只要增加于末尾，修改结构也不需要重建表数据。如果是存放可预先定义的属性数据呢？可以尝试使用SET类型，即使存在多种属性，同样可以游刃有余，同时还可以节省不小的存储空间。

5、字符编码：

字符集直接决定了数据在MySQL中的存储编码方式，由于同样的内容使用不同字符集表示所占用的空间大小会有较大的差异，所以通过使用合适的字符集，可以帮助我们尽可能减少数据量，进而减少IO操作次数。

（1）纯拉丁字符能表示的内容，没必要选择 latin1 之外的其他字符编码，因为这会节省大量的存储空间；

（2）如果我们可以确定不需要存放多种语言，就没必要非得使用UTF8或者其他UNICODE字符类型，这回造成大量的存储空间浪费；

（3）MySQL的数据类型可以精确到字段，所以当我们需要大型数据库中存放多字节数据的时候，可以通过对不同表不同字段使用不同的数据类型来较大程度减小数据存储量，进而降低 IO 操作次数并提高缓存命中率。

6、LOB类型：

强烈反对在数据库中存放 LOB 类型数据，虽然数据库提供了这样的功能，但这不是他所擅长的，我们更应该让合适的工具做他擅长的事情，才能将其发挥到极致。

二、表结构设计：

上面几点的优化都是为了减少每条记录的存储空间大小，让每个数据库中能够存储更多的记录条数，以达到减少 IO 操作次数，提高缓存命中率。下面这个优化建议可能很多开发人员都会觉得不太理解，因为这是典型的反范式设计，而且也和上面的几点优化建议的目标相违背。

1、适当拆分：

我们可能希望将一个完整对象对应一张数据库表，这对于应用程序开发来说是很友好的，但有时可能会在性能上带来较大的问题。当我们的表中存在类似于 TEXT 或者是很大的 varchar 类型的大字段的时候，如果我们大部分访问这张表的时候都不需要这个字段，我们可以将其拆分到另外的独立表中，以减少常用数据表所占用的存储空间。这样做的一个明显好处就是每个数据块中可以存储的数据条数可以大大增加，既减少物理 IO 次数，也能大大提高内存中的缓存命中率。

2、适度冗余：

冗余确实这样做会增大每条记录的大小，降低每条记录中可存放数据的条数，但是在有些场景下我们仍然还是不得不这样做，比如：被频繁引用且只能通过 Join连接 2张（或者以上）大表的方式才能得到的独立小字段，这样的场景由于每次Join连接仅仅只是为了取得某个小字段的值，Join到的记录又大，会造成大量不必要的 IO，完全可以通过空间换取时间的方式来优化。不过，冗余的同时需要确保数据的一致性不会遭到破坏，确保更新的同时冗余字段也被更新。

3、尽量使用 not null：

（1）null 类型比较特殊，SQL 难优化。虽然 MySQL null 类型和 Oracle 的 null 有差异，会进入索引中，但如果是一个组合索引，那么这个 null 类型的字段会极大影响整个索引的效率。

（2）很多人觉得 null 会节省一些空间，所以尽量让 null  来达到节省IO的目的，但是大部分时候这会适得其反，因为对于允许为 null 的字段，mysql 会多需要一个1字节记录是否为 null；同时也带来了很多其他的优化问题，不但没有将IO量省下来，反而加大了SQL的IO量。所以尽量确保 DEFAULT 值不是 NULL，数字可以默认0，字符串默认“”。