mysql数据库中的数据冗余如何处理

说白了，MySQL的数据冗余处理就是寻找一个平衡点。
不要积累太多垃圾，也不要过多减慢数据查询速度。

拓展一下，我们先来说说最重要的标准化设计。
这是标准答案。
比如我们去年跑的电商项目，orders表如果直接存储用户的完整地址，就显得过重了。
划分到用户表进行相关查询后，存储直接减半，避免了换地址的麻烦。
还有一点是外键关联。
对于产品分类等重复数据，创建一个单独的小表并使用外键关联。
更改类别名称时，更改一张表就足够了。
去年，我们的统计数据表明，这比更新整个表至少快 3 0%。
还有一个更重要的细节。
定期清洁是必要的。
例如，使用 GROUP BY user_id COUNT() > 1 可以快速识别重复的订单数据。
运行每周清理脚本后，表大小直接减少了 1 5 %。

一开始我以为非规范化就是直接打乱表，后来发现这是错误的。
预先保存订单总额等汇总字段确实可以省事，但需要触发器同步。
去年我就得到了因不同步导致报表数据连续3 天不正确的惨痛教训。

提醒：不要以偏概全。
对于有多次写操作的业务表，连接表相比之下，硬反规范化可能会很慢。

mysql中的数据冗余如何理解

数据冗余是指相同的数据存储在多个位置。

在MySQL中，employee表存储的是部门名称，这是多余的。
没有使用外键来映射独立的部门表。

典型表现：相同信息的重复存储。
员工表中的每条记录都存储部门名称。

优点是省事，不需要检查表格。
缺点是更新有问题。

更新异常：部门地址已更改，所有员工记录都需要更改。
如果失去了，那就是一场灾难。

插入异常：没有员工时，部门信息无法单独存储。

删除异常：所有员工均被删除，部门信息也丢失。

浪费空间：重复的数据占用磁盘空间。

解决方案：使用标准化。

创建一个独立的表来存储部门信息。
员工表存储部门编号（外键）。

创建外键约束以确保数字匹配。

使用JOIN来验证数据并确保一致性。

场景：当需要高性能时，可以进行反规范化。

保存汇总值，例如每月销售额。

复制该字段并将用户名存储在订单表中。

通过缓存，产品类别名称直接存储在缓存中。

称重点：一致性是个大问题，需要同步更新。
查询执行速度快，但数据写入速度慢。
维护复杂。

新：不要将优化视为缺陷。

以规范化的方式设计并存储在独立的表中。
当性能要求较高时，适当进行反规范化。

平衡一致性、性能和维护成本。

数据库冗余的优缺点是什么

老实说，数据库冗余有它的好处。
使用它的人越多，测试的速度就越快。
例如，如果您直接在一张表中检查用户信息、电话号码和地址，而无需连接到多个表，这会提高效率。

但是，这存在问题。
它确实占用了很多空间。
想一想，一张表存储相同信息的一份副本，两张表存储两份副本。
存储成本并不是一个可以轻易忽视的东西，尤其是在大数据的情况下。
如果金额很大，钱很快就会消失。

维护是一个大问题。
当数据需要改变时，例如用户的地址改变，所有表中的用户地址也必须改变。
假设您有三个表，它们都具有此地址字段。
如果更改第一个，则接下来的两个也必须更改。
缺一个吗？那么数据就乱了。
当时我不明白为什么有人会做出这样忘恩负义的事情。

系统的复杂性也随之增加。
字段越多，维护起来就越麻烦。
管理员每天都会处理这些重复的数据，这肯定很容易出错。
如果操作不当，丢失数据或无法更新将是一个大问题。

当然，并非所有情况都是不可能的。
对于一些特定的应用，比如游戏、玩家等级、设备等，可以存储在表中，可以快速查看，提供良好的用户体验。
在这种情况下，裁员将会带来回报。

但大多数情况下，你还是要设计好数据库。
合并的合并，联合的联合，不要冗余。
数据一致性和系统稳定性比快速测试重要得多。

说实话，用不用备份要看情况。
系统的需求和特点是什么，必须综合考虑。
没有统一的标准，要根据具体情况而定。