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 查询脚本全要检查。比起“像不像对象”，先问一句：这张表未来半年会被改几次？哪些字段大概率要加索引？哪些查询路径绝对不能变慢？
