重新认识Mysql之冗余字段的利与弊

在设计数据库时，我们往往依照数据库的范式降低数据间的冗余度，但是冗余字段就像是把双刃剑，在业务需求上,有效的增加数据的冗余度，还可以提高数据的访问效率。

什么是冗余字段?

个人理解为多张表中一致重复出现的字段,例如users表存在字段B,Wallet表也存在字段B,两张表中该字段业务.

1.空间换时间

当我们遇到数据量非常大的表时候,这时去做表的关联查询(Join)是非常虽然消耗系统性能的,甚至可能会出现数据库连接超时,crash等问题,这时就需要进行冗余设计,将部分字段冗余到关联表中,避免大表之间的关联查询,提高更快的响应速度.

2.业务快照

在电商系统开发中,交易场景大部分是数据快照.

用户下单时的收货人、地址、商品名称、商品描述、价格等字段,若采用关联表的设计,商品A在用户下单后发生了更新的话,再去进行关联查询就会导致和用户操作时的数据不一致,则会产生交易纠纷行为.

如:商品A 今天特价是100元,明天恢复原价200,用户A今天下单消费了100元,但是明天价格进行恢复了,用户申请了退款,需要系统退款200元,显然是不合理的存在.

为了系统的更健壮的运行服务用户,我们则需要进行设计冗余字段,来保证我们一些服务的可靠性.

系统开销大,维护成本高

当一张表上出现多个冗余字段时,每次更新某条记录,为了保证数据一致性,每次都需要去更新这些冗余字段,增加了系统开销和提高了维护成本.

数据一致性

当冗余字段使用的多了,数据一致性就难以保证,为了保证一致性就会产生很大的性能开销,如果某些冗余字段是采用人工维护(开发人员),数据一致性就会难以得到保障.

比如:某动态实际评论3条,冗余字段却显示了15,这样就会产生剩下的评论去哪了的问题.

空间的代价

表A存在5个冗余字段,随着业务量增长,表A每日新增数据1000万,久而久之这些冗余字段就会成为你储存部分的硬伤.

1. 遵循第三范式3NF,尽量减少冗余字段,不随便使用冗余字段.

2. 只在关键业务数据使用冗余字段,会让数据库执行性能更高、更快

3. 根据业务需求决定是否使用冗余字段,统计型字段可以使用json结构储存或建立冗余数据表,通过策略来维护和更新