MySQL不支持OOP，应避免用表模拟类、继承、多态；应依托关系模型设计，用应用层ORM映射对象，按需使用单表+role字段、JSON列或垂直拆分，外键仅用于强一致性场景。
MySQL 本身不支持 OOP，强行“OOP 化”设计反而有害
MySQL 是关系型数据库，没有类、继承、封装、多态等 OOP 概念。所谓“OOP 化设计”，常指把表结构硬套成类图（比如每个类建一张表、用外键模拟继承、加 type 字段做多态分发），这种做法会破坏范式、增加查询复杂度、拖慢 JOIN 性能，并让 SQL 变得难以维护。
真正该做的是：用好关系模型的表达力，再在应用层（Python/Java/Go 等）做 OOP 映射——ORM（如 SQLAlchemy、Hibernate）就是干这个的，不是让 MySQL 变成 OOP 引擎。
什么时候该拆表？别用“类继承”当借口
看到“用户有普通用户和管理员”就建 user 表 + admin 表 + 外键？大概率是错的。MySQL 没有“子类表自动关联父类字段”的机制，你得手动写 LEFT JOIN、反复 COALESCE 字段，还容易漏判 NULL。
更合理的方式：
- 单表 +
role字段（ENUM('user', 'admin')或VARCHAR(20)），权限和行为差异由应用逻辑控制 - 若字段差异极大（比如管理员有
audit_log_count，普通用户有preference_json），才考虑垂直拆分，但必须明确：这是为读写分离或索引优化服务，不是为“符合 UML 类图” - 真要模拟继承（极少数场景，如多种订单类型），用“单一表 +
order_type+ JSON 列存差异化字段”，比三张表 + UNION ALL 更易维护
外键不是 OOP 的“引用”，而是数据一致性的约束工具
很多人加外键只为“表示 A 属于 B”，像写 class Order { User user; }。但 MySQL 外键本质是：防止孤儿记录 + 自动级联动作。它带来锁开销、主从延迟风险、以及 DDL 阻塞（尤其大表 ALTER TABLE ... ADD FOREIGN KEY）。
建议：
- 核心业务强一致性场景（如资金流水必须绑定账户）才启用外键
- 高并发写入表（如日志、消息队列中间表）禁用外键，靠应用层校验 + 最终一致性补偿
- 不要为“看起来像对象关系”而加外键；
user_id字段存在 ≠ 必须加FOREIGN KEY (user_id) REFERENCES user(id)
JSON 字段不是逃避设计的万能胶，但比硬拆“OOP 子表”更务实
当需求频繁变更、属性稀疏（比如不同设备上报的传感器字段各不相同），与其建 10 张“device_xxx_metadata”表，不如用 JSON 列存结构化可变数据：
ALTER TABLE device_report ADD COLUMN metadata JSON;
优势明显：
- 写入快（无 DDL 成本）
- 查特定字段可用
metadata->>'$.battery_level'+ 生成列 + 索引加速 - 避免“每来一个新字段就 ALTER TABLE”导致的锁表风险
注意点：
- 别在
JSON里存关键业务字段（如金额、状态码），这些必须走原生列以保证原子性、索引效率和 SQL 可读性 - 别用
JSON_CONTAINS做高频 WHERE 条件——性能远不如普通索引
最常被忽略的一点：数据库设计的终点不是“像不像代码里的类”，而是“查得快、写得稳、改得少、看得懂”。ORM 可以帮你桥接对象与关系，但桥墩打歪了，桥再漂亮也塌得快。
