Mysql优化系列之表设计规范和优化

　　如果详细的讲范式，要写大大大篇文章来讲，这里假设大家知道一些基本的范式规则，我用简洁的语句和例子说明

　　第一范式：列不可再分，譬如地址字段，可以再细分为省市区门牌号等等（其实还是看需求怎么整）

　　第二范式：满足第一范式，且除主键以外的列都依赖于主键，这个好理解，订单表中不要有商品名，因为商品名依赖的

是商品id，应该放在商品表中，否则如果商品表中商品名字变了，订单表的商品名却是老数据

　　第三范式：满足第二范式，且非主键的列不存在传递性依赖，比如订单表中一种常见的不好的设计：

product_name依赖于product_id,product_id依赖于order_id,那么就应该把product_name移除，这是我们常说的冗余字段

　　范式的优点是结构简单，更新操作快，重复数据少，表规模更小

　　范式最大的缺点就是通常一些并不复杂的查询都需要关联，稍微复杂的可能要关联多次

　　如上，反范式的优缺点可以说跟范式正好相反，因为冗余了列，所以更新的时候需要同步更新过去（触发器很方便实现，但是

大公司一般拒绝这样做，因为出了错根本无从排查或很难补救，甚至于存储过程基本也是拒绝使用）。有了冗余列则不需要关联，

意味着使用索引等这样快速的查询更方便

　　实际开发基本都是这样做，是否要冗余还是不冗余，取决于业务，比如一个人的身份证不至于经常变（甚至不变），这样不怎么

变的字段完全可以冗余下来，避免连表查询。再比如count性质的字段，我们不会每次都用一个子查询去计算，而是增加这样一个字

段，每次增加记录后会更新该字段，诸如此类。

　　一些实时查询代价很大的，我们可以使用汇总表，以前用过复杂的视图，后来发现接触的数据量还是太小，量一上来数据库就要

崩，汇总表就是可以在一个固定的时间点或固定频率做一些汇总查询，将结果保存下来的表，这样每次查询直接拿查询结果即可。这

种设计可能增加写负担，但是显著的提高读性能

　　对于表中字段非常多的表，考虑根据字段意义类别再拆分出一个字表，对于某个字段中需要存储文件或长度很大的字段，也可以

单独拆出来，比如user表中的身份证照片，头像，写真这样的字段，可以独立出字表；

　　对于时间或者顺序迹象比较明显，数据量又很大的表，考虑分区处理

　　1、表名，字段名使用小写英文字母加下划线命名，用单数形式，表名以t_开头，尽量不要包含数字

　　2、除非有具体的理由，每张表应该有create_time和update_time两个字段

　　3、建议每张表都有自增id作为标识列

　　4、字段名最好不要超过3个单词连接，除非有业内熟知的单词缩写，用完整的单词

　　5、所有字段名尽量用业内熟知的英文单词，比如账户account，订单order，状态status，类型type

　　6、设计表时注意预留一些字段，比如常见的物理删除和逻辑删除，那么需要预留一个状态字段，如果是激活和非激活状态，也需

要设置一个状态字段

以上是一些比较理论的东西，实际开发设计表，还是需要知其然知其所以然的，否则有可能就是迷迷糊糊的不知道问题出在哪儿

巴特西