主键应优先用自增整数，避免业务字段或uuid；外键必须定义并按场景选择on delete/update动作，否则引发孤儿记录或数据不一致。
数据库查询变慢、连接超时、写入卡顿，往往不是服务器配置低，而是表结构里主键和外键没设计好——它们直接决定数据怎么存、怎么找、怎么关联。
主键选错，整张表就跑不快
MySQL的InnoDB引擎默认用主键构建聚簇索引，数据行按主键顺序物理存储。如果主键是UUID或字符串，会导致页分裂频繁、磁盘随机IO激增，查询性能断崖下跌。
第一步：优先用自增整数（BIGINT或INT）作主键，例如 id BIGINT PRIMARY KEY AUTO_INCREMENT。
第二步：避免用业务字段当主键，比如用手机号、身份证号、订单号——这些值可能变更、长度不一、插入无序，破坏B+Tree索引结构。
第三步：若必须用复合主键（如订单项表），确保组合字段顺序符合高频查询条件，且总长度控制在16字节以内，否则二级索引体积膨胀。
【复合主键中字段顺序错误会导致WHERE条件无法命中索引】
外键不是“可有可无”的装饰
没有外键约束时，订单表里的user_id可以随便填一个不存在的数字，系统运行一段时间后就会积累大量“孤儿记录”，JOIN查不出数据、统计结果失真、后台任务反复失败。
方法一：建表时直接定义外键，语法简洁且约束立即生效：
FOREIGN KEY (user_id) REFERENCES users(id) ON DELETE RESTRICT
方法二：已有表补加外键，必须先确保user_id列所有值都在users.id中存在，否则ALTER语句会报错中断。
【添加外键前未清理脏数据，会导致ALTER TABLE失败并锁表数分钟】
外键动作规则必须按场景选
ON DELETE和ON UPDATE后的动作选项，直接影响业务逻辑是否安全可靠。
① RESTRICT（默认）：禁止删除被引用的主表记录。适合用户表→订单表关系，防止误删活跃用户导致订单失效。
② CASCADE：主表删一行，子表相关行自动删。适合日志类表（如操作日志→用户表），但慎用于核心业务表，一次误操作可能清空整个关联链路。
③ SET NULL：主表记录删除后，子表外键字段设为NULL。前提是该字段允许NULL，且业务能容忍“归属未知”状态，比如客服工单表中的assignee_id。
这一步操作起来很简单，直接把ON DELETE CASCADE改成ON DELETE SET NULL就行，但改之前得确认应用层代码能处理NULL值，否则会抛出空指针异常。
