MySQL优化（1）：字段的设计，
Web项目中，当Java或者Go等语言速度提升到瓶颈的时候，我们需要关心MySQL的优化
可以优化的方面有很多：设计表、负载均衡、读写分离、SQL语句优化等
（1）IP地址设计
例如我们需要存储IP地址：192.168.1.1
第一反应是选用VARCHAR（15）；但是更好的方式是INT UNSIGNED（占用四个字节）
因为：IP地址可以很容易地转换为无符号整数
仔细观察IP地址，四部分都是0-255的数字，1个字节（8位）恰好可以表示0-255的整数
而MySQL有函数：inet_aton()：地址转成数字，inet_ntoa()：数字转成地址
示例：
SELECT INET_ATON('192.168.0.1')
结果：3232235521
SELECT INET_NTOA("3232235521")
结果：192.168.0.1
INT UNSIGNED占用字节少于VARCHAR(15)，并且整数查询效率更高（代价是需要使用转换函数）
总结：在设计字段的时候，尽量使用整数来表示字符串
（2）关联表设计
整型的优势：固定存储空间，通常是少量空间
例如：MySQL内部的枚举和集合类型：
enum(男，女，未知)
insert into user(gender) values(男)
这句话在MySQL中实际存储的是1，这就是最典型的把字符串存成整数
注意：实际中，很少使用mysql的enum和set，因为维护成果过高
比如性别需要把未知改为人妖，需要执行alter table modify column操作，需要独占整张表，检查记录性别值的合法性
如果一定要使用这种方式：关联表，字段id，title，存储1，男，2，女。这种方式使用较为广泛
但是，比如家庭地址这样的字符串，是无法改成整型的，不能强行操作
（3）金额存储
金额的存储对数据的精度要求较高，按理来说要使用DECIMAL()
例如DECIMAL(10,2)：有2位小数的定点数
实际中有另一种操作：INT或BIGINT，这时候为了精度不丢失，采用”分“为单位（12.51元记录为1251）
计算机中小数是无法做到不损失精度的，但是金额较特殊，固定了两位小数，所以可以采用这种方式
而且编程中，整数的计算相对于小数较为方便
DECIMAL也有擅长的地方，比如存储大数：123456789123456789
这时候不可以使用INT，只能使用BIGINT或者DECIMAL
注意：这里为什么我们不选择浮点数DOUBLE和FLOAT呢？因为浮点数会导致精度丢失
原因：浮点数占用固定的存储空间，无论存储多大的数，空间是一定的；但是定点数空间会随着数字变大而增加
由此引出了定长类型和变长类型：
定长类型：存储空间固定（INT、FLOAT、DOUBLE、CHAR、DATE、TIME、DATETIME、YEAR、TIMESTAMP）
变长类型：存储空间可变（VARCHAR、DECIMAL、TEXT）
注意：只有定长类型才会有损失精度的问题，定长类型效率较高
结论：在乎存储空间采用定长类型，在乎存储精度采用变长类型
（4）TEXT和VARCHAR的选择
TEXT：通常感觉存储容量较大，其实最大容量和VARCHAR的最大容量几乎一样
但是，TEXT是独立存储的，不占用字段的总空间，但是VARCHAR占用字段总空间，通常总空间是65535字节
结论：更大的数据还是采用TEXT更好
更大的数据类型有LONGTEXT，可以用于选择
（5）字段设计的原则
1.尽可能选择小的数据类型，这条无需多说
2.尽可能使用NOT NULL，因为数据库不需要判断是否为NULL，NULL在MYSQL中的存储和运算更麻烦：
NULL参与常规运算的结果都是NULL，当判断是否为空的时候，必须采用IS NULL和IS NOT NULL
MYSQL中每条记录会使用到额外的存储空间，用于表示每个字段是否为NULL
通常使用一个特殊的数据来占位，比如我要表达NULL通常设置为空字符串或者0
这种情况又会出现问题，比如成绩字段，0代表没有的话无法区分0分的学生，所以可以采用-1，消除歧义
3.字段注释要完整：gender int comment '性别'
4.单张表的字段数量不宜过多，通常最多二三十个；数量过多通常会出现某个业务逻辑只是用其中一部分，浪费性能
5.预留字段，比如field1 int field2 varcahr等等；后期项目如果需要更改表结构，这样做会方便很多
（6）关联表的设计
一对一：一条记录的字段较多，分布到多个表中存储
例如学生表，基础信息：姓名、身高、班级，还有一些不常用的数据：籍贯、家庭成员等信息
这时候应该设计基础信息一张表，不常用数据一张表，使用相同的主键来表示
一对多：在多的一端使用关联字段，关联一端的主键
例如文章和分类表，分类是一端，文章是多端；那么在文章表中需要有一个分类ID的字段做关联
多对多：使用中间表来实现
例如文章和标签，多对多，那么就需要一张表，字段至少有ID、文章ID、标签ID，每一条记录代表一个关联
（7）范式
第一范式：字段的原子性，不可再分割
关系型数据库默认满足第一范式，MYSQL满足
但也可以强行做：比如一个时间字段，同时写入开始时间和结束时间，这就不合理
一个容易出现的问题：（6）中的例子，文档和标签的设计中：如果我为了省事，不引入第三张表，而是在文章表中用一个字段标签IDs字段（例如存入1，2，3）
这种情况很常见，是不合理的做法，在更新的时候会出现很多问题，需要把逗号拆开处理，而且无法建索引
除非是类似日志系统，存入后不再维护，那么可以使用这种方式
第二范式：满足第一范式后，消除对主键的部分依赖（A字段可以确定B字段，那么B字段依赖A字段）
主键：可以唯一标识记录的字段或者字段集合
部分依赖：如果某个字段依赖复合主键的一部分字段，称之为对主键的部分依赖
例如一个课程信息表，字段有：老师，性别，班级，教室，时间，但是不存在ID
这时候需要我们选一个主键，这里面每一个字段都不能作为主键
老师和班级同时可以作为一个主键（复合主键）
但是性别对主键是部分依赖，如何消除呢？
部分依赖的产生必须是复合主键，那么增加一个ID即可消除对主键的部分依赖
第三范式：第二范式的基础上，消除对主键的传递依赖
传递依赖：C依赖于B，B依赖于主键，那么C对主键存在传递依赖关系
上门的例子：性别依赖于老师，老师依赖于ID，那么存在传递依赖关系
消除方式：将独立数据单独建表，使用关联字段进行存储
例子中，建立一个单独的表，记录老师和性别的关系
总结：独立数据独立建表；表中存在与业务逻辑无关的ID主键；表之间的关系由关联字段（或关联表）进行表示
通俗来讲：我们建表中，基本都是满足三大范式的