跟着强哥的兄弟，果然都是吃香的喝辣的。

大家好，我是皇子。

除了前段时间，京东的校招计划在8月1日就全面启动，招聘的岗位之多、范围之广之外。

怎么这几天听到的都是京东的好消息？--- 就说点跟我们技术相关的东西。

京东对校招的岗位薪酬全面上调，包括技术，薪酬上调比例还不低于20%，

如果入职的是“京东采销”（一个部门）可达全年20个月的薪酬结构，年终奖高达8倍月薪。

...太多了，京东显然是下了血本，看图

还有就是我的同事，昨天就在给我安利在京东看到的“广东够购家电可享政府补贴优惠20%”（京东搜：广东，就出来了）。

正常听到家电的补贴，我是雷打不动，不会去看一眼的～。

奈何同事的热心，手机滑动着屏幕地给我介绍：家电不止是冰箱洗衣机了，还有各种电脑、主机、显示器；补贴力度大，双十一都不一定有；主机性价比高，配个RTX 4060Ti 显卡自己配完价格也得5千多往上了。。。

我去看了一下，确实有自己看上的主机，好家伙，心也动了一下，但是好在卡里的余额没动。

其他的个大厂的好消息，等着各位朋友去探了，我们今天分享一个京东的校招后端开发的面经。

在技术面试的过程中，主要围绕着电商领域的数据库设计去的，问题也是由浅入深，这里就分享最核心的MySQL的范式部分。

MySQL的范式

范式理论本质上是为了解决四种异常：冗余数据、修改异常、删除异常、插入异常。

高级别范式的依赖于低级别的范式，1NF 是最低级别的范式。

第一范式（1NF）

1）定义：第一范式要求关系数据库中的每一列都是不可分割的基本数据项，即原子性。不允许存在重复组或集合。

假设有一个员工表，其中包含姓名、职位和技能。如果技能列包含多个值（如“编程, 设计”），则不符合1NF，应该将技能拆分成单独的表。

2）目的：消除重复数据项，确保每一列都是单一值。

第二范式（2NF）

1）定义：第二范式要求数据库表必须满足第一范式的要求，并且除了主键外，非主键列必须完全依赖于整个主键，而不是主键的一部分。

如，有一个学生表，包含学生ID、班级ID、课程名和成绩。如果班级ID和课程名共同构成主键，那么成绩列必须依赖于整个主键（学生ID + 班级ID + 课程名），而不仅仅是班级ID。

2）目的：消除部分依赖，确保非主键列依赖于整个主键。

第三范式（3NF）

1）定义：第三范式要求数据库表必须满足第二范式的要求，并且所有非主键列之间不能存在传递依赖。也就是说，除了主键外，所有非主键列都不能依赖于其他非主键列。

假设有一个部门表，包含部门ID、部门名和部门经理名。如果部门经理名依赖于部门名，那么就不符合3NF，应该将部门经理信息拆分到另一个表中。

2）目的：消除传递依赖，确保非主键列之间没有依赖关系。

💡Tips

通过过规范化设计，可以减少数据冗余、节省空间、并提高数据的一致性和完整性。

不同范式依次递进，从基本的原子性到更高级别的依赖关系消除，每一步都旨在简化数据库结构，提高效率和可靠性。

但在在实际应用中，根据具体需求选择合适的范式，有时为了性能或其他原因也会适当放松规范化的程度。一般互联网公司的设计都是反范式的，通过冗余一些数据，避免跨表跨库，利用空间换时间，提高性能。

设计表

现在有3个模块：用户、商品、订单，你会如何设计这些表？

（==结合业务的KnowHow，参考数据库的三大范式，适当冗余。==）

以上，点亮【赞与在看】让我们心中充满力量、披荆斩棘、不惧未来！

【推荐阅读】

虾皮面完，想开始摆烂

我们放弃JWT作为用户认证了

招了个牛逼架构师，把系统重构了，代码问题少了一半，老板决定裁一半人。