良好的表设计蛇高性能的基础.应该根据系统要执行的业务查询来设计.需要权衡各种因素.
1.范式设计:
范式来自英文Normal Form,简称NF.Mysql是关系型数据库,但是要设计好关系,必须满足一定约束条件.目前有六种范式.第一范式 第二范式 第三范式 巴斯-科德范式 第四范式 第五范式(又称完美范式).一般来说,数据库满足第三范式就行了.
2.第一范式:
属于第一范式的所有属性都不可再分.数据项不可再分.
第一范式强调数据表的原子性.demo如下:
name_age包含了两个列的属性.不符合第一范式.把它拆分成两个列如下:
编辑
3.第二范式:
第二范式是在第一范式的基础上建立来的.满足第二范式必须先满足第一范式.第二范式要求数据库表中的每个实例或行都可以被唯一的区分.通常在实现来说，需要为表加上一个列，以存储各个实例的惟一标识.也就是说表中只有一个业务主键.
一个订单有多个产品.订单id和产品id没有进行强关联.拆分如下.
一个订单有多个产品.订单id和产品id没有进行强关联.拆分如下.
编辑
这样就保证了数据完全依赖了主键.
4.第三范式:
每一个非主属性既不部分依赖于也不传递依赖于业务主键，也就是在第二范式的基础上消除了非主键对主键的传递依赖.例如，存在一个部门信息表，其中每个部门有部门编号（dept_id）、部门名称、部门简介等信息。那么在员工信息表中列出部门编号后就不能再将部门名称、部门简介等与部门有关的信息再加入员工信息表中.
如果我们改变了产品id对应的订单表中的产品名称也需要跟着更改.
5.反范式设计:
5.1概念:
反范式化就是为了性能和读取效率得考虑而适当得对数据库设计范式得要求进行违反。允许存在少量得冗余，换句话来说反范式化就是使用空间来换取时间.
5.2反范式设计:
因为商品信息和分类信息要经常一起查询.所以把分类名称也放到商品表里面.冗余存放.
6.范式化总结:
6.1优点:
范式化数据更新操作通常比范式化要快.
数据较好的范式化,会有很少的重复数据或者没有,所以会修改更少的数据.
范式化的表通常更小,可以更好地放到内存中.所以操作会更快.
很少有多余的数据意味着检索列表数据时更少需要DISTINCT或者GROUP BY语句.
6.2缺点:
通常需要关联.
7反范式化总结:
7.1优点:
可以减少表的关联.
可以更好地进行索引优化.
7.2缺点:
存在数据冗余及维护异常.
对数据的修改需要更大的成本.
8.工作中反范式实现:
完全的范式化和完全的反范式化设计都是实验室里才有的东西，在真实世界中很少会这么极端地使用。在实际应用中经常需要混用.
8.1性能提升计数器表:
假设有一个计数器表,只有一条数据.记录点击次数,每次点击都会对这条数据进行更新.对于要更新的事务来说,这条记录有全局事务锁.会使得查询更新次数变成串行化.降低并发性能.
8.2优化:
可以将计数器保存在多行中，每次随机选择一行进行更新.在具体实现上，可以增加一个槽（slot)字段，然后预先在这张表增加100行或者更多数据，当对计数器更新时，选择一个随机的槽（slot)进行更新即可。这种解决思路其实就是写热点的分散，在JDK的JDK1.8中新的原子类LongAdder也是这种处理方式.
不走到那里,可能谁也不会想到这就是来时的路.
如果大家喜欢我的分享的话.可以关注我的微信公众号
念何架构之路
