MySQL 本身不支持面向对象设计
MySQL 是关系型数据库，核心模型是表（
TABLE）、行（
ROW）、列（
COLUMN）和约束（
FOREIGN KEY、
CHECK等），没有类（
CLASS）、继承（
INHERITANCE）、封装或方法的概念。所谓“面向对象设计”直接映射到 MySQL 表结构，本质是误用术语——你不能在
CREATE TABLE里定义一个
virtual方法，也不能让一张表「继承」另一张表的字段。
但可以用关系模型模拟常见 OOP 场景
实际开发中，开发者常需将业务中的对象（如
User、
Admin、
Guest）落地为数据库存储。这不是靠 MySQL 支持 OOP，而是靠设计模式来桥接： 单表继承（Single Table Inheritance）：所有子类共用一张表，用
type或
role字段区分，冗余字段置
NULL；适合子类差异小、查询频繁的场景 类表继承（Class Table Inheritance）：父类建主表（如
users），每个子类建扩展表（如
admins含
user_id外键）；符合范式，但多表
JOIN成本高 具体表继承（Concrete Table Inheritance）：每个子类一张完整表（
users、
admins、
guests），无共享主表；避免
NULL，但字段重复、跨类型查询难
选哪种，取决于读写比例、是否需要跨类型聚合、ORM 是否支持（如 Django 的
MultiTableMixin或 SQLAlchemy 的
joinedload）。
ORM 层才是 OOP 逻辑的真正载体
把对象行为（
user.activate()、
order.calculate_total()）塞进数据库是反模式。正确分工是： MySQL 只负责持久化：存
status字段，不存
is_active()方法 ORM（如 Sequelize、SQLModel、Django ORM）负责映射：把
SELECT * FROM users WHERE id = 1结果实例化为
User对象，并挂载业务方法 触发器（
TRIGGER）或存储过程（
PROCEDURE）仅用于强一致性校验（如库存扣减），而非替代应用层逻辑
过度依赖
BEFORE INSERT触发器做状态流转，会让业务规则散落在数据库和代码两端，调试困难，测试成本飙升。
容易被忽略的性能与演化陷阱
看似“像 OOP”的设计，上线后常暴露问题：
JSON字段存对象属性（如
profile）：方便初期迭代，但无法建立索引、不能高效
WHERE查询、备份恢复慢、ORM 映射易出错 用
ENUM模拟状态机（如
status ENUM('draft','published','archived')）：新增状态需 ALTER TABLE，线上 DDL 锁表风险高；改用
VARCHAR+ 应用层校验更灵活 为“复用”强行抽象通用表（如
metadata表存各种实体的标签）：导致
entity_type+
entity_id联合查询慢、外键失效、难以加约束
真实项目里，宁可多建几张语义清晰的表（
orders、
subscriptions、
refunds），也不要堆一个“万能实体表”。MySQL 的优势在于确定性结构和可预测查询性能，不是灵活性。
