MySQL 原生不支持表结构继承（即没有
INHERITS或类似 PostgreSQL 的继承语法），也没有面向对象意义上的“子类表自动继承父类表字段”的机制。
为什么 MySQL 没有真正的表继承
MySQL 的设计哲学偏向简单、高效和可预测，表结构是扁平且显式定义的。它不提供语法级的继承声明，比如你不能写
CREATE TABLE employee INHERITS (person)—— 这会直接报错
ERROR 1064。
常见误解是把外键关联或 EAV 模式当成“继承”，但它们只是模拟，不是语言层支持的继承。
常用替代方案：单表继承（Single Table Inheritance）
把所有子类字段放在一张表里，用一个
type字段区分类型。这是最轻量、查询最快的模拟方式。
type列推荐用
ENUM或
TINYINT，避免字符串比较开销 子类特有字段允许为
NULL，但需在应用层保证逻辑一致性（比如
employee_salary只对
type = 'employee'有效） 索引设计要小心：混合类型查询可能无法高效利用索引
CREATE TABLE users (
id BIGINT PRIMARY KEY,
type ENUM('admin', 'customer', 'guest') NOT NULL,
email VARCHAR(255) NOT NULL,
admin_role VARCHAR(50) NULL,
customer_level TINYINT NULL,
created_at DATETIME DEFAULT CURRENT_TIMESTAMP
);
常用替代方案：类表继承（Class Table Inheritance）
每个“类”对应一张表，子表通过外键引用父表主键。语义清晰，符合范式，但 JOIN 成本高，ORM 映射复杂。
子表主键通常也是外键，指向父表id（例如
employee.id → person.id） 务必在子表外键列上建索引，否则
JOIN性能急剧下降 删除父记录时需考虑
ON DELETE CASCADE或应用层控制，否则容易出现孤儿数据
CREATE TABLE person ( id BIGINT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(100) NOT NULL, email VARCHAR(255) ); CREATE TABLE employee ( id BIGINT PRIMARY KEY, salary DECIMAL(10,2) NOT NULL, dept VARCHAR(50), FOREIGN KEY (id) REFERENCES person(id) ON DELETE CASCADE );
容易被忽略的关键点
没有数据库层强制约束来保证“每条
person记录必须属于且仅属于一个子类表”。这意味着： 插入时靠应用逻辑或存储过程校验，MySQL 本身不拦截非法状态 查询“所有员工信息”必须写
SELECT p.*, e.salary FROM person p JOIN employee e ON p.id = e.id，无法抽象成视图后完全透明 如果用 JSON 字段存子类扩展属性，虽灵活但丧失类型校验、索引能力和查询可读性
真正需要强继承语义的场景，建议换用 PostgreSQL；若坚持用 MySQL，就接受它是“模拟”，并在应用层补足约束和一致性逻辑。
