MySQL表结构应映射业务语义而非类图语法，用外键表达关联、单表继承+CHECK约束处理多态、TINYINT+注释替代字符串枚举，谨慎冗余低频变更字段以平衡性能与一致性。

MySQL 表结构不能直接套用类图，但可以映射核心关系

MySQL 是关系型数据库，没有继承、封装、多态这些面向对象概念。所谓“符合面向对象”，其实是把业务领域模型中的实体、关联、约束，用表、外键、索引、CHECK（8.0.16+）等机制合理表达出来。关键不是模仿语法，而是对齐语义。

• 用户 类 → users 表，字段对应属性，id 主键即对象标识
• “一个订单属于一个用户” → orders.user_id 外键引用 users.id，而非在 orders 表里存 user 对象实例
• “订单有多个商品项” → 拆成 order_items 关联表，体现一对多，不是把 JSON 数组塞进 orders.items

枚举和状态字段别用字符串硬编码，优先用 TINYINT + 注释或字典表

比如 order.status 字段，如果定义为 VARCHAR(20) 存 'pending'、'shipped'，会导致拼写错误、大小写不一致、查询慢、无法用数字索引加速。这不是“面向对象不好”，是关系模型下典型的反模式。

• 推荐：用 TINYINT UNSIGNED，值 0/1/2/3，配合列注释说明含义，例如 COMMENT '0: pending, 1: paid, 2: shipped, 3: completed'
• 更严格场景（如需运行时可配置、多语言支持）：建 order_status 字典表，orders.status_id 外键引用，避免魔法数字散落各处
• 避免用 ENUM：增删值需 ALTER TABLE，线上变更风险高；且 ORM 映射容易出错，比如 Django 的 choices 和 DB 实际值不同步

继承关系不要建父子表，用单表继承或类型字段 + 可空列

面向对象中 Payment 有子类 CreditCardPayment 和 AlipayPayment，不代表你要建三张表 payments、credit_card_payments、alipay_payments 并用外键关联——这会极大增加 JOIN 成本，也违背第三范式（字段依赖于主键，而非部分主键）。

• 更实用做法：单表 payments，含通用字段（id, amount, created_at），再加 type 字段（TINYINT 或 VARCHAR(16)），以及所有子类可能用到的可空字段，如 card_last4、alipay_trade_no
• 用 CHECK 约束保证字段互斥（MySQL 8.0.16+）：

  CHECK ((type = 1 AND card_last4 IS NOT NULL AND alipay_trade_no IS NULL) OR (type = 2 AND alipay_trade_no IS NOT NULL AND card_last4 IS NULL))

• 如果子类字段差异极大、读写比例严重倾斜，才考虑垂直分表（如 payment_cards 单独存卡信息），但必须由明确性能数据驱动，而非“看起来更像 OOP”

避免过度规范化导致 JOIN 泛滥，必要时冗余关键字段

例如 orders 表需要显示用户昵称，而 users 表可能频繁更新 nike_name。严格按范式，每次查订单都得 JOIN users；但若业务要求列表页响应快、且昵称变更不频繁，可在 orders 中冗余 user_nickname 字段。

• 冗余前提：该字段变更频率低（如用户改昵称每月不到 1 次）、一致性可接受（允许几秒延迟）、且能通过应用层或触发器/事件驱动同步
• 绝不冗余主键、时间戳、金额类核心事实字段——这些一旦不一致，会导致账务错误
• JOIN 不是原罪，但 5 张表以上 JOIN + 分页 + ORDER BY，在千万级数据下基本不可维护；先看执行计划（EXPLAIN），再决定是否冗余

实际设计时，最常被忽略的是「变更成本」：一张表加个字段简单，但加完后所有 INSERT/UPDATE/SELECT/ORM Model/缓存 Key/日志格式/BI 查询脚本全要检查。比起“像不像对象”，先问一句：这张表未来半年会被改几次？哪些字段大概率要加索引？哪些查询路径绝对不能变慢？