MySQL不支持面向对象特性，只能通过表结构、外键、视图等模拟静态结构：用type字段实现单表继承，外键实现组合关系，视图封装查询逻辑，但无法真正封装行为（如方法）。
MySQL 本身不支持类或对象实例，但可以用表结构模拟对象行为
MySQL 是关系型数据库，没有原生的类、继承、封装或方法概念。所谓“模拟面向对象”，本质是用表设计 + 外键约束 + 视图/存储过程来逼近 OOP 的常见建模意图——比如把一个“用户”看作对象，它的属性（name、email）、关联（orders 表）、类型区分（user_type）都靠表和约束表达。
用主表 + 子表实现单表继承（Single-Table Inheritance）
当多个“子类”共享大部分字段时，最轻量的做法是统一存一张表，用 type 字段区分角色，并允许部分字段为 NULL。例如模拟 User、Admin、Guest：
CREATE TABLE users (
id BIGINT PRIMARY KEY AUTO_INCREMENT,
type ENUM('user', 'admin', 'guest') NOT NULL,
name VARCHAR(100) NOT NULL,
email VARCHAR(255),
admin_level TINYINT NULL, -- 仅 admin 有效
last_login DATETIME NULL, -- 仅 user/guest 有意义
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);注意点：
-
ENUM或VARCHAR字段必须显式维护类型一致性，应用层需校验，数据库无法强制“admin_level只能出现在type = 'admin'时” - 查询某类对象要加
WHERE type = 'admin'，否则容易漏过滤 - 字段越多、子类差异越大，NULL 值越密集，空间和语义清晰度越差
用外键 + 关联表实现组合与一对多关系（替代 has-a / belongs-to）
OOP 中的组合（如 User 拥有多个 Address）在 MySQL 中直接对应外键引用。关键不是“模拟对象”，而是明确谁是主实体、谁从属：
CREATE TABLE users ( id BIGINT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(100) );CREATE TABLE addresses ( id BIGINT PRIMARY KEY AUTO_INCREMENT, user_id BIGINT NOT NULL, street VARCHAR(255), city VARCHAR(100), country CHAR(2), is_primary BOOLEAN DEFAULT FALSE, FOREIGN KEY (user_id) REFERENCES users(id) ON DELETE CASCADE );
常见陷阱：
- 忘记加
ON DELETE CASCADE，导致删users后留下脏addresses - 误把
is_primary当成唯一约束——需配合唯一索引：UNIQUE KEY unique_primary_per_user (user_id, is_primary)，否则无法保证每人只有一个主地址 - 应用层读取“用户+主地址”时，习惯写
JOIN，但若用户无地址，LEFT JOIN才不会丢数据
用视图封装常用对象查询（避免重复 JOIN 和条件）
每次查用户都要连 addresses、profiles、roles？视图能固化这种“对象组装逻辑”，让 SQL 更接近调用对象属性：
CREATE VIEW user_summary AS SELECT u.id, u.name, u.email, a.street AS primary_street, a.city AS primary_city, p.avatar_url, GROUP_CONCAT(r.role_name) AS roles FROM users u LEFT JOIN addresses a ON u.id = a.user_id AND a.is_primary = TRUE LEFT JOIN profiles p ON u.id = p.user_id LEFT JOIN user_roles ur ON u.id = ur.user_id LEFT JOIN roles r ON ur.role_id = r.id GROUP BY u.id, a.id, p.id;
注意事项：
- 视图不存储数据，只是保存 SELECT 语句；性能取决于底层表索引是否覆盖查询字段
- 不能对含
GROUP BY或JOIN的视图直接INSERT/UPDATE（多数情况不可更新） - 别名如
primary_street就是“对象属性”的投影，但本质仍是扁平字段，没有方法或状态
真正难的是行为建模：比如“用户登录”这个动作，在 MySQL 里只能拆成“UPDATE users SET last_login = NOW() WHERE id = ?”，没法封装成 user.login()。所有“对象方法”最终都得由应用代码或存储过程承担——而后者调试难、移植差、事务边界模糊。所以，表结构能模拟的只是静态结构，别指望靠它绕过应用层职责划分。
