MySQL不支持面向对象设计，其核心是关系模型而非类、继承等OOP概念；可通过单表、类表或具体表继承模式在关系模型中模拟OOP场景；ORM承担对象行为封装，MySQL仅负责数据持久化。
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 的优势在于确定性结构和可预测查询性能，不是灵活性。
