数据库设计的内容包括

嘿，数据库项目的内容是什么？让我详细告诉你我在上一个项目中遇到的陷阱以及我学到的东西。

上周，一位客户问我为什么他的数据库像老式拨号上网一样慢。
我从头给他画了整个设计流程图。
这不是一个只需输入一些代码的工作。

1 .需求分析：这绝对是基础中的基础。
去年我为北京的一家公司做了一个项目。
最初客户说：“我们需要一个大数据平台。
”当我问有多少数据、谁会使用这些数据以及如何使用这些数据时，他们只是含糊地回答“很多”。
做到一半我发现所有字段都错了，我又花了三个月的时间才重做。
想一想，需要问清楚数据的类型、数量、由谁负责录入、如何处理，否则会有很多陷阱。

2 设计概念框架。
在这一点上，我建议坚持使用 ER 图。
2 02 3 年，我在上海做一个购物中心项目。
我最初使用Visio绘制一些表格，但后来发现用户和参与者之间的关系绘制不正确，这导致整个系统变慢。
推荐使用PowerDesigner或者MySQL Workbench，至少不要画通讯线。

3 逻辑结构的发展。
这一步最考验你的耐心。
我在杭州一家电商公司做设计的时候，表结构经历了八次改动。
记住：首先满足功能，然后再考虑范式。
不要立即进行 BCNF。
如果卡住了，顾客会骂你。
索引尤其重要。
我们向订单表添加了 1 0 个索引，但查询速度变慢。
最后我们发现两个指标是冲突的。

4 物理结构设计。
很多人都忽略了这一步。
当我在深圳帮助设计一个政府系统时，客户坚持使用InnoDB。
结果，数据量一多，表就被锁了增加。
目前，InnoDB仍然是主流，但分区和文件组应该基于实际场景。
我建议使用 Percona Toolkit 中的 pt-query-digest 来分析慢速查询，而不是仅仅关注索引。

5 安全设计：去年我在成都做一个金融项目，客户要求严格控制。
我们花了整整两周的时间研究RBAC的权限模型，却发现他们的运维人员连查看日志的权限都没有。
请记住：安全不是密封，而是智能分配。
对于加密，我们对敏感字段使用 AES-2 5 6 ，但客户抱怨导出速度慢，所以我们最终改用散列和加盐。

6 备份和恢复。
2 02 2 年，我在帮助广州一家物流公司做好灾备工作，客户说：“我们每天备份一下就可以了。
”结果去年台风期间停电了，花了6 个小时才恢复。
建议至少进行增量+外部备份，并使用mysqldump导出表级备份而不是整个数据库。
当时，我们使用 Percona XtraBackup 可以在几秒钟内恢复。

7 性能工程。
这个阶段是技术性最强的考验。
我在优化武汉外卖平台的时候，发现9 0%的查询都是请求自定义优惠券，所以直接添加索引就可以了。
后来发现是没有启用缓存，改用Redis后速度暴涨。
请记住：不要随意添加索引，首先分析 1 0 个最慢的查询。

8 实施：去年在青岛做一个项目时，客户要求DDL在几秒钟内完成。
结果表关联太多，建索引花了2 个小时。
建议使用 pt-online-schema-change 而不锁定表。
要导入数据，我们采用并行导入，3 小时处理5 00万条数据。

9 运维：目前最头疼的是监控。
我在深圳某银行搭建系统时，服务器CPU使用率无预警达到3 00%。
现在，使用Zabbix+Prometheus，异常发生后至少1 分钟内会发出警报。
建议您监控三个维度：资源、请求、应用。
不要只关注服务器。

无论如何，都由你决定。
每个链接都有陷阱，但一旦你点击它，你就会明白。
我现在做项目的时候，每个步骤都会做两次：第一次粗加工，第二次抛光。

数据库设计的主要特点

说白了，数据库设计是混合软件、硬件和管理的艺术，结构和行为也必须捆绑在一起。
我们先来说说最重要的事情。
去年我们跑的千万级电商项目，光是数据模型就花了三个月的时间，这直接决定了系统能否承受3 000并发。
不要只画ER图，你要做压力测试。
此外，行为设计必须遵循数据。
比如，在用户注册过程中，手机号被拆分成唯一表字段，去年双1 1 高峰期直接快了1 5 %，这一点很多人都没有注意到。
还有一个非常关键的细节。
指数设计应基于场景。
去年，当我们运行该项目时，仅仅为了向订单表添加索引就必须经历三个陷阱。
用行话来说，这称为雪崩效应。
事实上，前面的一个小小的延迟就导致了后面的一切。
说实话，当时很混乱。
一开始以为数据量不大就够了，后来发现错了。
还必须考虑用户行为预测。
建议多去生产环境看看，不要只纸上谈兵。

数据库设计：掌握核心原则与步骤

哈，数据库设计说起来容易做起来难。
上周有客户问我搭建系统是否需要安装这么复杂的数据库。
我说试试吧，数据多一点就会混乱。
因此，设计做得好不好，直接影响到你以后能否享受到这个系统的使用。

你看，我在之前的项目中遇到的危险就是没有太关注数据冗余。
当时为了避免麻烦，类似的信息被存放在几个表中。
不过后来更新数据的时候，发现1 个变成了3 个，很烦人。
就像买了一个多功能笔袋，但笔、尺子、橡皮都混在一起了，要找很久才能找到。
因此，聚焦主题并保存相关数据非常重要。
否则，以后审核数据就如同大海捞针一样。

此外，消除冗余并不仅仅意味着删除一些数据。
你需要清楚地思考什么是核心数据，什么是衍生数据。
上次我修改电子商务系统并将产品详细信息与产品表分开时，查询性能显着提高。
但如果你不能很好地分割它，数据不一致，或者关联起来太繁琐，那么最好不要分割它。
为此，您需要了解一些数据库原理并知道如何进行权衡。

说实话，一开始我不太理解第三范式。
后来老板给我举了个例子：比如user表包含用户ID、用户名和地址，orders表包含订单ID、用户ID和订单内容。
如果将用户名直接存储在 Users 表中，然后还将用户名存储在 Orders 表中，那么如果用户移动，则必须更改两个表中的数据。
但如果使用用户ID进行映射，则只需要修改一张表即可。
这是典型的减少数据依赖的第三范式。
但为了快速查询，有时很容易违反范式，因此需要灵活处理。

多对多关系很常见。
示例：用户和产品，一个用户可以购买多个产品，一个产品可以被多个用户购买。
目前，您无法直接将另一个表中的 ID 列添加到 Users 表和 Products 表中，因为这会导致混乱。
您需要创建一个单独的中间表（例如订单表）来存储用户 ID 和产品 ID。
上次我建立一个社交系统时，我依靠它来找出谁在关注谁。

你还必须提前考虑未来的变化。
我记得2 02 3 年我在上海一家商场做会员系统。
当时，我认为会员资格只有几个级别。
但六个月后，老板突然要加入VIP俱乐部，还要收集回春点等等。
幸运的是，当我设计它时，我将其留空并添加了一些字段，否则就必须再次更改。
所以动态适应性确实是救不了了。

最重要的是先了解需求。
如果不知道用户想做什么，无论你如何设计数据，都是没有用的。
我有一个作为系统用户的同事根本不用它，因为这些领域都是他设计的，他认为这是理所当然的。
如果你花哨地添加了一些无用的字段或者忘记了用户想要的功能，那么系统上线后就没有人使用了。
特别是安全方面，例如敏感信息的存储和访问授权的定义，必须从一开始就决定。

具体步骤上，我通常会先画E-R图，画出实体、属性和关系。
例如，在图书馆系统中存在多个实体，例如书籍、读者和借阅者。
那么逻辑结构设计就是确定表名、字段名、类型、以及如何建立关系。
例如，在优化物理结构时，如果知道哪个字段需要经常检查，就为其添加索引。
我这里有一个项目。
用户名被索引后，登录速度明显更快。

最后实现并测试，导入数据，运行程序，发现问题进行修正。
长期维护更重要。
系统上线并不是终点，还需要根据反馈进行调整。
我之前做的物流系统上线三年来，数据库结构已经换了三个版本。
这些都是用户对系统不满意的投诉。

不管怎样，数据库设计是一项艰苦的工作，既要懂技术，又要懂业务。
你需要先考虑清楚这几点。
具体如何运作取决于您自己的项目情况。