mysql一对多关系通过外键约束实现，即从表外键指向主表主键或唯一键；外键列需与被引用列类型严格一致且被引用列须有索引，外键本身不自动创建索引，建议手动添加以提升join和级联操作性能。
MySQL 一对多关系对应的是外键 + 主键约束，不是“对象引用”
MySQL 本身没有对象概念，所谓“类比对象”容易误导——它不存储对象实例，只存数据行和约束。一对多在数据库里体现为：从表（“多”的一方）用 FOREIGN KEY 指向主表（“一”的一方）的 PRIMARY KEY 或 UNIQUE 列。
比如订单（orders）和订单项（order_items）：每个订单可有多个订单项，但每个订单项只属于一个订单。这时 order_items.order_id 是外键，关联到 orders.id。
- 外键列必须与被引用列类型严格一致（包括是否
UNSIGNED、字符集、排序规则） - 被引用列必须有索引（
PRIMARY KEY自带索引，但若引用的是普通UNIQUE列，需手动建索引） - 外键不自动创建索引，建议手动为外键列加索引（否则
JOIN或delete CASCADE性能极差）
ORM 层才真正做“对象关联”，MySQL 不参与这部分逻辑
像 django ORM、SQLAlchemy、mybatis 这些框架，在代码里定义 Order.items 这样的属性，是运行时通过 SQL 查询拼装出来的“虚拟对象关系”。MySQL 只负责执行底层 select ... JOIN 或分步查询。
例如 SQLAlchemy 中：
class Order(Base): __tablename__ = 'orders' id = Column(Integer, primary_key=True) items = relationship("OrderItem", back_populates="order") <p>class OrderItem(Base): <strong>tablename</strong> = 'order_items' id = Column(Integer, primary_key=True) order_id = Column(Integer, ForeignKey('orders.id')) # 这里才是 MySQL 真正看到的 order = relationship("Order", back_populates="items")</p>注意：relationship() 定义完全不改变 MySQL 表结构；它只影响 ORM 如何生成和执行 SQL。
- 如果不设
ForeignKey，ORM 可能仍允许定义relationship，但关联查询会出错或返回空 -
back_populates和backref是 ORM 内部双向绑定机制，MySQL 压根不知道它们的存在 - 级联删除（
cascade="all, delete-orphan"）最终翻译成ON DELETE CASCADE或由 ORM 手动发多条DELETE语句
别把“一对多设计”和“查询性能”混为一谈
很多人以为加了外键就自动优化了 JOIN，其实不然。外键只保证数据一致性，不提升查询速度。
- 查一个订单及其所有订单项，典型写法是：
SELECT * FROM orders o JOIN order_items i ON o.id = i.order_id WHERE o.id = ? - 如果
order_items.order_id没有索引，这个 JOIN 会全表扫描order_items，哪怕只有几千行也明显变慢 - 复合查询（如按商品统计销量）往往需要
GROUP BY+count()，这时更依赖索引覆盖和执行计划，跟外键无关
真实瓶颈常出现在：没给外键列建索引、JOIN 多层后未限制结果集、N+1 查询（ORM 默认懒加载引发）。
最容易被忽略的点：NULL 和级联行为必须显式约定
MySQL 外键默认允许 NULL，而很多业务场景中，“多”的一方不允许孤立存在（比如订单项不能没有订单）。这时候必须加上 NOT NULL 约束。
另外，ON DELETE 行为不设等于不生效：
-
ON DELETE NO ACTION（默认）：删主记录前检查子记录，有则报错 -
ON DELETE CASCADE：删主记录时自动删所有子记录（小心误删） -
ON DELETE SET NULL：要求外键列允许NULL，且对应字段得是NULLable
这些行为在建表时就要定死，后期修改需 DROP FOREIGN KEY 再 ADD，线上环境风险高。