SQL数据库建模应从业务操作倒推结构设计，聚焦查询性能、更新稳定性与扩展性，通过梳理业务动线识别实体关系、合理分表分索引、权衡范式与冗余，并预留版本、租户、软删除等演进字段。
SQL数据库建模不是先画ER图再写CREATE TABLE，而是从“业务要查什么、改什么、数据怎么来”倒推结构设计。核心是让常用查询快、关键更新稳、后续扩展不翻车。
先理清业务动线，再定实体和关系
别一上来就分用户、订单、商品三张表。先问清楚：用户下单时要填哪些字段？订单创建后哪些状态会变？谁可以修改价格？退款时要追溯到哪一步？把这些操作流程写下来，自然能识别出：
- 哪些是独立变化的主体（比如“订单状态”适合单独建状态表，而不是用字
符串枚举） - 哪些字段总是一起出现（比如收货人姓名+电话+地址，大概率该拆成“收货地址”子表）
- 哪些操作需要原子性保障（比如扣库存+生成订单，得靠事务，也意味着这两部分数据最好在同库甚至同表合理分区）
符串枚举）主键和索引不是越多越好，而是按查询模式配
一个WHERE条件没走索引，十倍优化都白搭。建模阶段就要预判高频查询：
- 查“某用户最近10笔订单” → 用户ID + 创建时间联合索引（注意顺序：等值字段在前，范围字段在后）
- 按日期汇总销量 → 订单表里日期字段单独建索引，或考虑按月分区
- 模糊搜商品名（LIKE '%手机%'）→ 普通B+树索引无效，得上全文索引或ES同步
别给所有外键自动加索引——只有被WHERE、JOIN、ORDER BY实际用到的才加。
避免过度规范化，也警惕过早反范式
第三范式（3NF）能减少更新异常，但现实里常要权衡：
- 用户表里存“城市名称”还是“城市ID”？如果城市极少变动、查询总要连带显示，冗余名称+加注释说明来源，比每次JOIN更稳
- 订单表是否存商品名称和单价？是。因为订单快照必须锁定当时值，不能依赖商品表实时读取
- 但“用户性别”这种低基数、高一致性字段，仍建议用字典表+外键，方便统一管理与校验
留好演进接口：版本、租户、软删除
上线后加字段容易，改结构难。建模时提前埋点：
- 每张业务表加 create_time / update_time DATETIME NOT NULL，默认CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
- 多租户系统必加 tenant_id，且所有查询WHERE默认带上，避免数据越界
- 删数据别直接DELETE，加 is_deleted TINYINT DEFAULT 0，并在所有SELECT加 AND is_deleted = 0；索引可包含该字段提升过滤效率
基本上就这些。建模不是一步到位，而是随着第一个真实查询慢下来、第一个并发修改报错、第一次导出数据对不上，不断回看、微调的过程。
