必须通过外键约束和主键约束的物理实现来识别主键与外键：外键字段位于“多”端表并引用“一”端主键，需显式定义foreign key约束，且被引用列必须为主键或unique not null；仅字段名含“_id”不构成外键。
要从数据库表关系中准确识别主键和外键，必须先理解一对多和多对一关系在物理表结构中的具体实现方式，而不是仅靠逻辑描述或ER图臆断。
一对多关系的物理实现
第一步：在“多”端表中添加外键字段，该字段引用“一”端表的主键。
例如：订单表（orders）与客户表（customers）是一对多关系，订单表中必须存在 customer_id 字段。
第二步：为该外键字段建立外键约束，指向“一”端表的主键列。
执行 SQL：ALTER TABLE orders ADD CONSTRAINT fk_customer_id FOREIGN KEY (customer_id) REFERENCES customers(id);
第三步：确保“一”端表的被引用列是主键或具有唯一且非空约束。【若 customers.id 没有定义 PRIMARY KEY 或 UNIQUE NOT NULL，外键约束将创建失败】
这一步不能跳过——没有主键或唯一约束的列无法被外键引用，否则数据库会直接报错。
多对一关系的本质就是一对多的反向表述
多对一不需额外建模，它和一对多共享同一套物理结构：外键始终落在“多”侧表中。
比如“多个订单属于一个客户”，从订单视角看是多对一，但从客户视角看就是一对多。
方法一：用表名+字段名直接判断
只要看到某张表里有另一个表的主键名（如 user_id、category_id），且该字段未设为主键，基本可判定它是外键，指向对方的主键。
方法二：查数据字典或 SHOW CREATE TABLE
运行 SHOW CREATE TABLE orders;，在输出中找 CONSTRAINT 行，能明确看到 FOREIGN KEY 定义及 REFERENCES 目标。
验证主键外键是否真实生效
执行 SELECT CONSTRAINT_NAME, CONSTRAINT_TYPE FROM INFORMATION_SCHEMA.KEY_COLUMN_USAGE WHERE TABLE_SCHEMA = 'your_db' AND TABLE_NAME = 'orders';
结果中 CONSTRAINT_TYPE 为 PRIMARY KEY 的行对应主键，为 FOREIGN KEY 的行对应外键约束。
注意：仅字段名含 “_id” 不代表就是外键——必须存在 FOREIGN KEY 约束定义，否则只是普通字段。【没有约束的“外键字段”无法保证参照完整性，删掉主表记录时不会报错，极易引发脏数据】
尝试插入一条 orders 记录，customer_id 填写一个不存在的 customers.id 值，如果数据库拒绝插入并报错 “Cannot add or update a child row”，说明外键约束已生效。
