大家好，这一篇主要围绕三个特点记录。
mysql数据库设计
- 数据库设计三大范式
- 数据库表字段类型分析
- 不推荐存储的数据类型
1.数据库设计三大反式。
- 范式分为:3大范式，以及BC范式，第四范式还有第五范式 一共六大范式通常来说满足与三大范式就基本 足够 ;
- 注意:项目的数据库设计并不一定要完全满足与三大范式，有些时候我们会适量的冗余让Query尽两减少 Join
- 误区:不是范式越高越就越好 好 => 结构清晰
- 早期:希望数据可以足够的小数据量不是问题主要分问题 现在:希望查询速度越快越好,同时操作越简单越好。
1.1 第一范式(1NF)
第一范式要求关系中的属性必须是原子项,即不可再分的基本类型，集合、数组和 结构不能作 为某一属性出现，严禁关系中出现“表中有表”的情况在任何一个关系数据库系统中，第一范式是关系模 式 的一个最起码的要求。不满足第一范式的数据库模式不能称为关系数据库。
1.2 第二范式(2NF)
第二范式(2NF)是在第一范式(1NF)的基础建立起来的，既满足第二范式(2NF)就必须要 满足第一范式。第二范式(2NF)要求实体的属性完全依赖于主键字。
第二范式(2NF)要求实体的属性完全依赖于主关键字。所谓完全依赖是指不能存在仅依赖主关键字一部分 的属性，如果存在，那么这个属性和主关键字的这一部分应该分离出来形成一个新的实体，新实体与原实 体之间是一对多的关系。为实现区分通常需要为表加上一个列，以存储各个实例的唯一标识。简而言之， 第二范式就是在第一范式的基础上属性完全依赖于主键。
1.3 第三范式(3NF)
第三范式(3NF)是第二范式的子集，既满足第三范式就必须满足第二范式。意思是不存在非 关键字段对任意候选关键字段的传递函数依赖。
其实就是把表进行拆分，然后在关系表存上依赖关系的id。
2. 数据库表字段类型分析
2.1 字符串类型
char和varchar都是用来存储字符串类型的数据,但是他们保存和检索的方式不一样.char属于固定长度的字符类型, varchar属于可变长的字符类型。
由于char是固定长度的,所以它的处理速度比varchar快得多,但是其缺点是浪费存储空间,程序需要对尾行空格 进行处理,所以对那些变化不打并且查询速度有较高的 要求的数据可以考虑使用char类型来存储。
在mysql中,不同的存储引擎对char和varchar的使用原则有所不同 MyISAM存储引擎建议使用固定长度的数列代替可变长度的数据列 InnoDB存储引擎
建议使用varchar类型,对于InnnoDB数据表,内部的行存储格式没有区分固定长度和可变长度,因此使用 char列不一定比 可变长度的varchar性能好 由于char平均占用空间多余varchar,因此varchar来UI消化需要处理的数据航的存储总量和磁盘I/O是比较 好的。
2.2 数字类型
d 必为主键，类型为int bigint unsigned、单表时自增、步长为 1; 注意一下因为一些表可能因为数据量的关 系导致主键会很大可能会超出int的范围这个时候就比较建议使用bigint通常int即可。
注:不过当一个表数据量超过了500万的时候或者单表容量超过2GB的时候推介分库分表;这一步操作是需 要实先对于数据量在项目上线之后的思考点UNSIGNED属性就是将数字类型无符号化, unsigned的使用 注意 unsigned tinyint 的范围就是 0-255。
2.3 时间类型
- 注意: 默认情况下，当MySQL遇到超出范围的日期或时间类型的值或该类型的其他无效值时，它会将该值 转换为“零”值的值。唯 一的例外是超出了范围。TIME值被裁剪 到TIME范围。
- MySQL允许在DATE或DATETIME列。这对于需要存储您可能不知道确切日期的生日的应用程序非常有用。在 这种情况下， 您只需将日期存储为'2009-00- 00'或'2009-01-00'。如果存储这样的日期，就不应该期望得到 正确的结果，例 如DATE_SUB()或DATE_ADD()需要完整的日期。若要在日期中不允许零个月或日部分，请启 用NO_ZERO_IN_DATE模式 。
- MySQL允许您存储“零”价值'0000-00-00'作为“假约会。”在某些情况下，这比使用NULL值，并使用较少的数 据和索引空 间。不允许'0000-00-00'，启用NO_ZERO_DATE模式。
3. 不推荐存储的数据类型
- 二进制多媒体数据 将二进制多媒体数据存放在数据库中，一个问题是数据库空间资源耗用非常严重， 另一个问题是 这些数据的存储很消耗数据库主机的CPU 资源。这种数据主要 包括图片，音频、视频和 其他一些相关的二进制文件。 这些数据的处理本不是数据的优势，如果我们硬要将他们塞入数据库， 肯定会造成数据库的处理资源消耗 严重。
- 流水队列数据 我们都知道，数据库为了保证事务的安全性(支持事务的存储引擎)以及可恢复性，都 是需要记录所 有变更的日志信息的。而流水队列数据的用途就决定了存放 这种数据的表中的数据会不 断的被 INSERT，UPDATE 和 DELETE，而每一个操作都会生成与之对应的日志信息。在 MySQL 中，如 果是支持事务的存储引擎，这 个日志的产生量 更是要翻倍。而如果我们通过一些成熟的第三方队列软 件来实现这个 Queue 数据的处理功能，性能将会成倍的提升。
- 超大文本数据 对于 5.0.3 之前的 MySQL 版本，VARCHAR 类型的数据最长只能存放 255 个字节，如果 需要存储 更长的文本数据到一个字段，我们就必须使用 TEXT 类型(最大 可存放 64KB)的字段，甚至 是更大的LONGTEXT 类型 (最大 4GB)。而 TEXT 类型数据的处理性能要远比 VARCHAR 类型数据的 处理性能低下很多。从 5.0.3 版 本开始 ，VARCHAR 类型的最大长度被调整到 64KB 了，但是当实际数 据小于 255Bytes 的时候，实际存储空间和实际的数据长 度一样，可一旦长度超过 255 Bytes 之后，所 占用的存储空间就是实际数据长度的两倍。 对于图片的存储，如果说是 特殊情况可以使用BLOB，但 是通常来说跟推介使用varchar存图片路径，而图片会放在一个文件夹中
