Mysql 表的设计需要从两个方面进行：
- 逻辑设计（范式设计，反范式设计）
- 物理设计（命名规范，存储引擎选择，数据类型选择）
重要性：如果表设计的不好，sql语句再怎么优化也没用，主要避免多表join,大数据量用join可能会急剧变慢,因为笛卡尔积的缘故
逻辑设计：
范式设计：
数据库设计的第一大范式：
- 数据表中的所有字段都只具有单一属性。
- 单一属性的列是由基本数据类型所构成的。
- 设计出来的表都是简单的二维表。
数据库设计的第二大范式：
- 要求表中只具有一个业务主键，也就是说符合第二范式的表并不能存在非主键列只对部分主键的依赖关系。(抽出一张关系表)
数据库设计的第三大范式：
- 指每一个非主属性即不部分依赖也不传递依赖与业务主键，也就是在第二范式的基础上相处了非主键对主键的依赖性。
范式设计的问题：完全符合范式规范设计有时候并不能得到良好的sql查询语句。因为出现的表过多，会出现多 join的情况
范式设计的优点：
- 可以尽量的减少数据的冗余。
- 范式化的更新操作比反范式化更快
- 范式化的表通常比反范式化更小
范式设计的缺点：
- 对于查询需要对多个表进行关联
- 更难进行索引优化
反范式设计：
反范式化是针对范式化而言的
所谓反范式化设计就是为了性能和读取效率的考虑而适当对数据库设计范式的要求进行违反
允许存在少量的冗余，换句话来说反范式化设计就是使用空间来换取时间。
优点：
- 减少表关联，更好的查询，可以更好的进行索引的优化。
缺点：
- 存在数据冗余及数据维护异常。
- 对数据的修改需要更多的成本。
总结：
不能完全按照范式化设计，要根据实际业务，适当的进行反范式化，考虑以后如何使用表。
物理设计
根据所选的关系型数据库的特点对逻辑模型进行存储结构的设计。
- 定义数据库，表，及字段的命令规范
- 选择合适的存储引擎
- 为表中的字段选择合适的数据类型
- 建立数据库结构。
定义数据库，表，及字段的命令规范
- 数据库，表，字段的命名要遵守可读性原则：使用大小写来格式化库对象名(驼峰或者下划线)
- 数据库，表，字段的命名要遵守表查性原则：对象名字应该能描述它表示的对象
- 数据库，表，字段的命名要遵守长命原则：尽量不使用缩写。
选择合适的存储引擎
读多写少 ：MyISAM
写多读少(并发量大)：Innodb
为表中的字段选择合适的数据类型
当一个列可以有多种类型时：
- 优先考虑数字类型
- 其次是日期，事件类型
- 最后是字符类型
- 对于相同级别的数据类型，应该优先选择占用空间小的数据类型。
浮点类型时：
若与财务有关，优先使用 DECIMAL
列类型 | 存储空间 | 是否精确类型 | 数据是否丢失 |
FLOAT | 4个字节 | 否 | 是 |
DOUBLE | 8个字节 | 否 | 是 |
DECIMAL | 每4个字节存9个数字，小数点占一个字节 | 是 | 否 |
时间类型：
timestamp 与 datetime区别：
timestamp 和时区有关(4个字节)，datetime无关（5.6之后 5个字节，之前8个字节）
学习年限不足，知识过浅，说的不对请见谅。
世界上有10种人，一种是懂二进制的，一种是不懂二进制的。
本文章为转载内容，我们尊重原作者对文章享有的著作权。如有内容错误或侵权问题，欢迎原作者联系我们进行内容更正或删除文章。
