主键是表中唯一标识每一行且非空唯一的字段或组合，需显式声明NOT NULL和唯一性；外键用于引用完整性，仅InnoDB支持，要求父表有索引、类型字符集严格匹配。
主键（PRIMARY KEY）是什么，怎么加才有效
主键是表中唯一标识每一行的字段（或字段组合），MySQL 要求它非空（NOT NULL）且值唯一。定义不当会导致插入失败、索引失效，甚至无法建表。
常见错误：用 VARCHAR(255) 字段当主键却不加 NOT NULL；或者用 INT 但忘了设 AUTO_INCREMENT，结果插入时没给值就报错。
- 单列主键最常用：
CREATE TABLE user ( id INT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(50) );
- 复合主键要谨慎：只有真正需要联合唯一约束时才用，比如
(order_id, item_seq)，但后续关联查询和索引效率会变复杂 - 主键自动创建聚簇索引，所以别随便用长字符串（如
VARCHAR(200)）做主键——索引体积大、写入慢、JOIN 性能差
外键（FOREIGN KEY）怎么声明，为什么有时加不上
外键用于强制引用完整性，即子表某列的值必须在父表主键/唯一键中存在。但它不是“加了就生效”，MySQL 中只有 InnoDB 引擎支持外键，MyISAM 完全忽略 FOREIGN KEY 语法（不报错也不生效）。
典型失败场景：ERROR 1215 (HY000): Cannot add foreign key constraint，多数因为以下几点：
- 父表和子表引擎不一致（一个 MyISAM，一个 InnoDB）
- 父表被引用字段没有索引（必须是主键或有独立索引）
- 数据类型不严格匹配：比如父表是
INT UNSIGNED，子表是INT，就不行 - 字符集或排序规则不同（如父表用
utf8mb4_unicode_ci，子表用utf8mb4_general_ci）
正确写法示例：
CREATE TABLE order_item ( id INT PRIMARY KEY AUTO_INCREMENT, order_id INT NOT NULL, product_id INT NOT NULL, FOREIGN KEY (order_id) REFERENCES `order`(id) ON DELETE CASCADE, FOREIGN KEY (product_id) REFERENCES product(id) );
ON DELETE 和 ON UPDATE 的实际影响别想当然
外键的级联行为不是“可有可无的装饰”，它直接决定数据一致性策略。用错可能批量删掉不该删的数据，或导致更新卡死。
-
ON DELETE CASCADE：删父记录时自动删所有子记录。适合强依赖关系（如订单删了，明细必须一起删），但要注意应用层是否已做校验——数据库删了，应用缓存可能还留着脏数据 -
ON DELETE SET NULL：要求子表对应字段允许为 NULL，否则建表失败；若该字段上有非空约束或业务逻辑禁止为空，就会出问题 -
ON UPDATE CASCADE：父表主键被改（极少推荐！），子表自动同步。但主键本不该被更新——如果真需要改，说明设计有问题，优先考虑用逻辑 ID + 业务字段分离
不显式声明时，默认是 RESTRICT（拒绝操作），这是最安全的默认值。
主键和外键在真实业务中常被绕过的原因
很多团队后期禁用或不用外键，并非因为它们没用，而是运维和扩展成本太高。
- 分库分表后，跨库外键无法实现，硬加反而让 DDL 变得脆弱
- 大批量导入数据时，外键检查拖慢速度，常需临时
SET FOREIGN_KEY_CHECKS = 0，但容易忘记开回来 - ORM 或微服务架构下，约束逻辑移到应用层更灵活（比如软删除、异步清理），数据库只管存储
- 开发环境用 SQLite 或测试 MySQL 实例没开 InnoDB，外键形同虚设，上线才发现不一致
真正关键的是：主键必须存在且合理设计；外键则要看团队对一致性的容忍度、运维能力与系统阶段——新项目可以开，老系统加外键前务必先查存量数据是否合规。
