表的设计及优化：

数据表范式：

第一范式：属性(字段)的原子性约束，要求属性具有原子性，不可再分割；

第二范式：记录的惟一性约束，要求记录有惟一标识，每条记录需要有一个属性来做为实体的唯一标识。

第三范式：属性(字段)冗余性的约束，即任何字段不能由其他字段派生出来，在通俗点就是：主键没有直接关系的数据列必须消除(消除的办法就是再创建一个表来存放他们，当然外键除外)

当然，其实我们经常打破第三范式。。。且不可避免的，其实就是要在数据冗余和处理速度之间找到合适的平衡点 。

关于字段属性：

1）建议不要使用DOUBLE，不仅仅只是存储长度的问题，同时还会存在精确性的问题。

2）对于整数的存储，在数据量较大的情况下，建议区分开 TINYINT / INT / BIGINT 的选择（当然，那已经是很老的事情了，现在其实不差这点性能）

3）char是固定长度，所以它的处理速度比varchar快得多，但缺点是浪费存储空间，不能在行尾保存空格。在MySQL中，MyISAM建议使用固定长度代替可变长度列；InnoDB建议使用varchar类型，因为在InnoDB中，内部行存储格式没有区分固定长度和可变长度。

4） 尽量不要允许NULL，除非必要，可以用NOT NULL+DEFAULT代替。

5）text与blob区别：blob保存二进制数据；text保存字符数据，有字符集。text和blob不能有默认值。

实际场景：text与blob主要区别是text用来保存字符数据（如文章，日记等），blob用来保存二进制数据（如照片等）。blob与text在执行了大量删除操作时候，有性能问题（产生大量的“空洞“），为提高性能建议定期optimize table 对这类表进行碎片整理。

6） 自增字段要慎用，不利于数据迁移

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

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

9）尽量使用TIMESTAMP类型，因为其存储空间只需要 DATETIME 类型的一半，且日期类型中只有它能够和实际时区相对应。对于只需要精确到某一天的数据类型，建议使用DATE类型，因为他的存储空间只需要3个字节，比TIMESTAMP还少。（真的是技术文，欢迎补充）

关于表的拆分：

垂直拆分：（列的拆分，将原来一个有很多列的表拆分成多张表）

在数据表设计之初就执行的步骤，然后查询的时候用join关联起来即可

拆分原则：（缺点就是使用冗余字段，经常需要join操作）

  • 不常用的字段单独放在一起
  • 把text、blob等大字段拆分出来放在附表中
  • 经常组合查询的列放在一张表

水平拆分：（表的记录太多，则以该表主键的某个值为分界线分隔）

①：数据库的表越少越好

②：表的字段越少越好

③：字段中的组合主键、组合索引越少越好