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

jiezi

5 年前

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

什么是冗余字段?

个人理解为多张表中一致重复出现的字段, 例如 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 结构储存或建立冗余数据表, 通过策略来维护和更新

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