数据模型是抽象层，描述业务实体、属性及逻辑关系；表设计是实现层，将模型落地为CREATE TABLE语句。
什么是数据模型，它和表设计不是一回事
数据模型是抽象层，描述业务实体、属性及它们之间的逻辑关系；而表设计是实现层，把模型落地为 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行为
一对多、多对多，怎么选中间表还是冗余字段
一对多（如一个用户多个订单）直接在「多」侧加外键字段，没问题。但多对多（如用户和角色、文章和标签）必须用中间表，不能靠逗号分隔存字符串——那等于放弃查询、索引、事务能力。
解析 MySQL 8.0 的 DDL 脚本，并将表结构导出为 Excel 格式。适用于用户需将 MySQL 的 `CREATE TABLE` 语句转换为结构化的 Excel 文件场景，导出内容包含字段名、数据类型、长度及精度等信息。支持多张表的批量处理，每张表对应 Excel 中的一个独立工作表。适用于数据库文档编写、数据字典生成及模式分析等任务。
中间表不是随便起名，它本身应具备业务含义，比如 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 再改。
