什么是数据模型，它和表设计不是一回事
数据模型是抽象层，描述业务实体、属性及它们之间的逻辑关系；而表设计是实现层，把模型落地为 MySQL 中的
CREATE TABLE语句。很多人一上来就写
CREATE TABLE user，却没想清楚「用户」在业务里是否要拆成
user_profile、
user_credential、
user_setting—— 这种拆分不是为了炫技，而是由访问频次、更新频率、权限边界决定的。
比如登录态只读
user_credential（含密码哈希、盐值），而头像昵称存在
user_profile；两者用
user_id关联，但能独立加索引、分表、甚至跨库。
外键要不要开，MySQL 8.0 和 5.7 差别很大
MySQL 默认存储引擎 InnoDB 支持外键，但线上环境多数关掉，原因很实际：
ON DELETE CASCADE容易误删整条链路数据；
ALTER TABLE加外键会锁全表；分布式事务或分库分表后外键失效。
更常见的做法是：应用层做约束校验 + 数据库加普通索引 + 注释说明逻辑关系。
必须建索引：若order表有
user_id字段，且常用于
JOIN或
WHERE，就得加
INDEX idx_user_id (user_id)命名统一：外键字段名建议与被引用主键一致（如都叫
user_id），避免
uid/
owner_id混用 MySQL 8.0+ 可用
FOREIGN KEY ... REFERENCES做 DDL 文档化，但不启用
CASCADE行为
一对多、多对多，怎么选中间表还是冗余字段
一对多（如一个用户多个订单）直接在「多」侧加外键字段，没问题。但多对多（如用户和角色、文章和标签）必须用中间表，不能靠逗号分隔存字符串——那等于放弃查询、索引、事务能力。
中间表不是随便起名，它本身应具备业务含义，比如
user_role比
user_role_map更准确；如果需要记录分配时间或状态，就别省字段：
CREATE TABLE user_role ( user_id BIGINT NOT NULL, role_id TINYINT NOT NULL, assigned_at DATETIME DEFAULT CURRENT_TIMESTAMP, is_active BOOLEAN DEFAULT TRUE, PRIMARY KEY (user_id, role_id), INDEX idx_role_id (role_id) );
注意：
PRIMARY KEY (user_id, role_id)同时保证唯一性和联合索引效率；单独建
idx_role_id是为了反向查「某角色下所有用户」。
时间字段用什么类型，TIMESTAMP 和 DATETIME 别乱换
TIMESTAMP自动转时区（存 UTC，读取时转当前会话时区），
DATETIME纯存储不转换。线上服务若部署在多时区机房（如阿里云华东+华北），又用了
TIMESTAMP，就可能查出「时间倒流」或「同一条记录显示不同时间」。
通用建议：
记录创建/更新时间一律用DATETIME，配合应用层写入固定时区时间（如
Asia/Shanghai） 不要依赖
DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP做审计，因为无法区分是程序更新还是 DBA 手动改的 需要长期归档的字段（如合同生效时间），必须用
DATETIME，否则 2038 年问题会提前爆发（
TIMESTAMP有范围限制）
最常被忽略的是：ALTER 修改字段类型时，
ALTER TABLE t MODIFY created_at DATETIME不会自动补默认值，已有 NULL 数据会导致失败，得先
UPDATE再改。
