MySQL表结构不按范式设计易导致查不准、改不动、删不了；1NF要求字段原子化，如tags需拆为关联表；2NF要求非主键字段完全依赖联合主键，商品信息应独立成表；3NF消除传递依赖，部门经理应移至departments表。
为什么 MySQL 表结构不按范式设计，上线后容易出事
因为没满足范式，数据一多就「查不准、改不动、删不了」。比如用户地址存在 10 张订单表里，改个地址要 UPDATE 10 次；新增一个还没下单的 VIP 客户，却因缺少订单 ID 而插不进客户信息；删掉最后一条订单，顺手把客户记录也干掉了——这些不是 bug，是设计缺陷。
1NF：字段不能“塞一堆东西”
违反 1NF 最常见的就是用一个 VARCHAR 字段存多个值，比如 tags VARCHAR(255) 存成 "java,mysql,backend"。这会导致：
• 无法用 WHERE tags = 'mysql' 精准查询
• INDEX 失效，LIKE '%mysql%' 全表扫
• 后续加标签、去重、统计都得靠应用层字符串处理
正确做法是拆成关联表：
• article_tags(article_id INT, tag_id INT)
• tags(id INT PRIMARY KEY, name VARCHAR(50))
2NF：联合主键时，别让字段“只认一半主键”
典型错误场景：订单明细表用 (order_id, product_id) 当联合主键，但把 product_name 和 category 直接放进来。问题来了：
• product_name 只依赖 product_id，和 order_id 无关 → 违反 2NF
• 同一商品在不同订单里重复存 50 次名字，冗余爆炸
该怎么做：
• 把商品信息全挪到独立的 products 表
• order_items 表只留 order_id、product_id、quantity
• 查详情时用 JOIN products ON order_items.product_id = products.id
3NF：别让字段“靠别的字段中转才能找到主键”
传递依赖的坑很隐蔽。例如员工表里有 emp_id（主键）、dept_name、dept_manager，而 dept_manager 实际由 dept_name 决定（市场部→张三，技术部→李四）。这就构成：emp_id → dept_name → dept_manager，中间绕了一道。
后果：
• 换部门经理时要批量 UPDATE 所有该部门员工记录
• 部门名拼错（如“技木部”），对应经理也跟着错
• 新增部门但没员工，经理信息根本存不进去
解法很简单：
• 拆出 departments(dept_name, manager)
• 员工表只保留 emp_id 和 dept_name（或更好：用 dept_id 外键）
• 查询时 JOIN departments 获取经理
范式不是教条，但跳过它前得清楚代价：每次为省一次 JOIN 而冗余字段，都是在给后续的 WHERE 条件、索引策略、数据校验埋雷。尤其当业务从单体走向微服务、报表需求变多、DBA 不再是你自己时，那些当初“图省事”的字段，会变成最慢的查询、最难对齐的数据、最不敢动的表结构。
