我记得很清楚，自己第一次独立设计数据库表结构的时候，满脑子都是“字段齐了就行”。结果表是建出来了，上线一个月就开始难受：用户要按时间筛选，发现日期存的是字符串；要做数据统计，发现状态字段中文英文混着来；产品要加个会员等级，发现得同时改五张表。那时候我才反应过来，数据库设计根本不是“建几张表”的事，它决定了你未来一年是天天写简单查询，还是天天为了一张破表做各种补偿逻辑。这篇就是把这些年踩过的坑、沉淀下来的原则，一次性整理清楚，给正在做表设计或者准备重构数据模型的同学当个参考。
很多人写数据库设计原则爱从理论开讲，什么范式、什么完整性约束，一套套的。我不打算这么来，我更愿意按着“真实业务怎么推着你去设计表”的顺序，把那些好用的习惯、容易翻车的细节、以及背后“为什么必须这么干”的逻辑讲明白。这里头没有一条是“为了规范而规范”，每条背后都对应着至少一个我亲手填过的坑。
1. 为什么数据库设计总是被拖到“最后一步”，然后疯狂返工
先说个我观察到的普遍现象：大多数项目的开发节奏是“先写接口，再补表”，甚至有人是“代码跑通了，才发现没地方存数据”，这时候才回头建表。这种流程带来的结果就是，表结构完全服务于当前这一版代码，压根没考虑数据将来要经历什么。短期看效率挺高，但“能用”和“好改”是两码事。
1.1 表结构本质上是“永不卸载的接口”
我后来想明白一个道理：表结构比接口更像接口。接口升级了你大不了换个版本，老客户端强制升级就行；但一张表一旦上了生产，里面有真实数据，你要改字段类型、要拆表、要合并表，每一步都得考虑数据迁移、历史数据兼容、还有那些你根本不知道在哪跑着的定时任务。改表的成本，通常比改接口高一个数量级。所以，设计表的时候你就得假设，这张表要活五年、十年，这期间业务规则变十次，但表结构尽量只加字段、不改语义，更不能推倒重来。
这其实就是数据库设计原则的底层逻辑：不是追求“当前最正确的模型”，而是追求“未来最好改的模型”。我见过太多人为了“灵活”搞出一堆设计，结果改一个需求要动六张表；也见过保守到把所有东西塞一张宽表里的人，加个字段就得锁表。走极端都不行，得在中间找那个“未来变更成本最低”的点。
1.2 设计不良的三类隐性代价
细数一下，表设计失败的代价基本归成三类。
第一类是迁移成本。业务跑了一年，突然发现订单表里把“会员ID”和“用户ID”混着存了，想拆开得写复杂的清洗脚本，还得担心拆的过程中产生脏数据。每次做这种迁移，我都是加班到凌晨，改完还要盯几天报表有没有异常。
第二类是查询性能劣化。典型的例子是，设计的时候图省事，把逗号分隔的标签直接存一个字符串字段，比如tags: "水果,生鲜,折扣"。查询“所有生鲜商品”时，只能全表扫一遍再 LIKE，数据量到百万级就等着超时吧。这就是把“该在关系里表达的数据”塞进了标量里，等于主动放弃了数据库的索引能力。
第三类是数据质量失控。没有约束、没有规范，同一个含义的字段在不同表里叫法不一样，同一个状态在这张表是数字、那张表是字符串，连应用层都不知道哪个是准的。最后的结果就是，报表没人信，系统里全是“历史原因”造成的脏数据。数据质量一出问题，整个团队对数据的信任就崩了，后面的分析、决策全部变成猜。
1.3 把“原则”理解为“约束的保护”，而不是“流程的束缚”
有些开发一听“设计原则”就头大，觉得是 DBA 或者架构师拿条条框框来限制自己。实际工作几年后我的体会正好反过来：这些原则是保护你的。拿“数据类型严格”来说，你存日期就用日期类型，应用层想传个乱七八糟的字符串进来，数据库直接报错，这难道不是帮你挡掉脏数据吗？拿“外键约束”来说，虽然大厂高并发场景经常禁用物理外键，但在中小体量的系统里，一个外键能防止你写出“删了用户但订单里还留着孤立的用户ID”这种逻辑错误。
我现在的态度很简单：设计原则是“防守策略”，它不保证你能做出最华丽的设计，但能保证你不出大事故。出大事故的设计，基本都有一条共性——设计者太相信人的“自觉”，不相信约束。可实际上，业务一变，代码一乱，人的自觉是最靠不住的。
2. 先立规矩：表与字段命名里的门道和纪律
命名看着是小事，实际上命名规范是表结构长期可维护性的第一道防线。我接手的每个烂摊子项目，第一感觉就是“看不懂”：a、b、temp1、test2这种表和字段比比皆是，要不就是同一个含义今天叫createtime，明天叫create_time，后天叫gmt_create。就别提什么外键字段完全看不出指向哪张表的事了。
2.1 表名的两个大方向：单数还是复数，前缀加不加
关于表名单数还是复数，社区吵了十年也没吵完。我的立场很明确：统一用单数。user而不是users，order而不是orders。理由很简单：表是一个“实体集合”的模板，你读出数据的时候是一个个对象，ORM 映射的时候类名也都是单数。你顺手写SELECT * FROM users也没毛病，但和代码的命名习惯一对照，单数更顺。关键是团队里必须只有一种选择，否则有人写user有人写users，那就是灾难。
第二个争议点是前缀。在一些老项目里，你会看到t_user、tb_order、sys_config这种写法。我的建议是：除非公司有统一规范，否则别加t_前缀。前缀本身不携带信息，纯属噪声。但“业务模块前缀”可以加，比如订单域的表统一order_开头，order_main、order_item、order_pay_record，这样在茫茫表海里一眼就能认出同一个域的表，尤其在库里有几百张表的时候，这个前缀是真的能救命。反过来，没有域概念，全是user_info、user_address、user_credit_log这种以“主体”为中心的表，也可以不加域前缀，完全看团队习惯。核心是：有规律、无例外、一眼懂。
2.2 字段命名：每个字段都要能读出“唯一含义”
字段命名的第一原则是“含义唯一”，也就是一个字段名在整个库里不能有第二种解释。最常见的翻车点是时间字段：create_time、created_at、gmt_create、createTime都表示“创建时间”，能不能统一？我现在的库里强制所有表统一用create_time、update_time、delete_flag这种小写下划线风格，应用层也不需要针对每张表写不同的映射规则。
再说外键字段。凡是“指向某张表”的字段，命名格式统一为“目标表名单数语义 +_id”。订单表里指向用户的字段就叫user_id，指向商品的叫product_id，千万别叫uid或者pid——缩写节省的几个字符，换来的是未来每次写 JOIN 都得翻表结构确认，太亏了。布尔字段加is_前缀，枚举/状态字段直接用状态本身的单词，如order_status，不要叫status_flag或者flag。这里我强烈建议所有“状态类”字段都配上注释，写明每个枚举值代表的含义，最好连业务流转关系也写进表注释里，因为状态字段是后来者最容易猜错的东西。
2.3 主键与逻辑删除的规范要统一
主键命名没什么好说的，但这里有两个容易犯的错。第一个是拿业务字段当主键，比如用手机号、身份证号做用户表主键。业务字段一变，你的主键就得跟着变，还会引发一系列关联表的外键连锁更新。正确做法是搞一个与业务无关的代理主键，业务唯一性用unique key兜底。第二个是不同类型的主键混用，有的表用bigint，有的表用varchar，JOIN 的时候性能天然吃亏，类型不统一也容易埋坑。
逻辑删除我用得比物理删除多，但也最怕没规矩。字段统一delete_flag，0代表正常、1代表删除，默认0，加索引。千万别一个表叫is_deleted，另一个表叫deleted，值含义还分成0/1和Y/N。还有，逻辑删除字段要放进唯一索引里做联合，比如unique(user_id, delete_flag)，否则用户二次注册时“明明删了却提示已存在”。
2.4 用注释把“设计意图”留下来
命名之余我最后想强调一个很多人忽略的动作：写注释。字段注释、表注释，必须写。一张表刚建出来时设计者当然懂字段含义，但半年后、换了一个人、甚至换了一整个团队后，没有注释的表就是天书。我经手过一个系统，有个字段叫ext，注释是空的，问了三个当初参与开发的人，三个人给出三种解释。自那以后我养成了一个习惯，每个字段都写注释，状态枚举直接列全：0-待支付 1-已支付 2-已取消。这个动作多花 30 秒，但能救后来人 3 小时。
3. 范式不是面试八股，它是帮你省钱的数学工具
说到范式，很多人的反应是“面试背过，实际不咋用”。其实不是范式没用，而是没把它放在“权衡”里去用。范式化解决的核心问题是：避免数据冗余和更新异常。你想想，同一份数据存在十几个地方，那更新的时候就得同步改十几处，漏一处就是脏数据。范式化的过程，本质上是在“拆开”这种风险。但拆得太狠也有代价：查询要 JOIN 一堆表，性能变差。所以真正的功夫是知道什么时候拆，什么时候故意不拆。
3.1 三大范式，用大白话讲一遍
第一范式：字段不可再分。说人话就是，一张表的每个字段存一个独立含义的数据，别在一个字段里塞一组值。比如hobbies: "篮球,足球"就不符合，尽管很多人这么干。
第二范式：非主键字段必须完全依赖于主键，不能只依赖主键的一部分。这主要针对联合主键的场景。比如一张选课表的主键是(student_id, course_id)，那你不能把“学生姓名”放进去——它只依赖student_id，不依赖整个联合主键，这就会导致同一个学生选了五门课，他的名字在表里存五份，改一次得改五行，属于典型的“部分依赖”。
第三范式：非主键字段不能依赖于其他非主键字段。最经典的就是把“部门名称”直接存在员工表里。部门名称依赖于“部门ID”，部门ID才是员工表的字段，而部门名称跟员工ID没有直接关系。这属于“传递依赖”，带来的问题同步修改成本高，部门改名得 UPDATE 一堆员工行。
3.2 用订单场景拆一遍：该拆的必须拆
举个我经常拿来做培训的例子——订单表。很多人第一版设计喜欢把所有能塞的全塞进一张表：order_id, user_id, user_name, user_phone, address, product_id, product_name, product_price, quantity, total_amount, create_time。这表刚建出来的时候确实好使，查询只要一张表全搞定。可后来麻烦了：同一个用户下了十单，user_name和user_phone存了十份，用户改了手机号，你得先找出他所有历史订单，全部同步更新；而且一旦漏更新，历史订单显示旧号，客服查单就对不上。
按范式拆，就是把“用户基础信息”拆到user表，“订单主体”拆到order表（只留id, order_no, user_id, status, total_amount, create_time），订单里的商品明细拆到order_item表（id, order_id, product_id, product_name, product_price, quantity）。你发现没有，product_name和product_price我故意留在明细表里了——这是“快照”思想：商品名称和价格未来可能变，但订单里的商品信息必须是你下单那一刻的。这不叫违反第三范式，这叫合理冗余，是为了业务正确性。
这种拆法带来的好处立竿见影：用户改手机号只需要 UPDATE 用户表一行；商品改名不影响任何历史订单；订单表和明细表之间用 JOIN 查询。代价是查询多了一次 JOIN，但在绝大多数业务中，这个代价远小于同步更新和脏数据的代价。
3.3 什么时候“故意不范式化”才正确
但范式化不是万能药。有些场景，我设计时会刻意“反范式”。第一类是读多写少的聚合数据。比如商品详情页要展示“销量”和“评价数”，如果每次请求都去 COUNT 订单和评价表，数据库压力你扛不住。正确做法是商品表里冗余两个字段sale_count、comment_count，下单和评价的事务里顺手 +1。这种冗余换来的是查询性能十倍提升，带来的风险是计数偶尔不准，但绝大业务都能接受。
第二类是日志和流水类数据。操作日志、登录记录这种数据，几乎只读不更新，也不会有人拿它做复杂的多表关联。这种情况下你甚至可以不设计主键、不用外键，全字段随缘冗余，重点是写入吞吐和查询效率，不是范式。我见过矫枉过正的人给登录日志做三个范式拆分，把用户信息、设备信息、IP 归属地全部拆开，结果查一次日志 JOIN 五张表，日志查询接口慢得没法用，这是把范式用错地方了。
第三类是关系型数据库里的“文档结构”。比如订单的收货地址快照，用户可能改了地址，但历史订单必须还是旧的。这同样不是“冗余失控”，而是“数据版本化”的合理设计。
3.4 判断要不要拆的那把尺子
拆不拆，我一般拿三个问题衡量：这个问题多久会被更新一次？每次更新涉及多少行？查询是会更频繁还是更少？如果答案是“经常更新、牵扯多行、查询不频繁”，坚决拆；“不更新、纯展示、查询很热”，可以合理冗余。数据库设计原则从来不是铁律，而是在写放大和读放大之间做取舍。想清楚这把尺子，范式的“度”自然就出来了。
4. 字段类型选错，代价在三年后兑现
字段类型是数据库设计里最“细碎”但又最影响长期使用体验的部分。很多人建表时随手varchar(255)到处用，所有数字都上int，时间一律datetime，等数据涨起来、查询慢下来，再回头改字段类型，那就是一场生产事故级别的迁移。我建议大家在第一步就把类型选对，省掉后面的苦。
4.1 整数类型：别用 int 装所有数字，也别给手机号用 int
整数的选择遵循“够用且留余量”原则。TINYINT是 1 字节，范围 -128~127，无符号 0~255，状态码、数量、星级打分类，这不是正好吗？SMALLINT2 字节，最大 65535（无符号），存年龄、库存余量都可以。INT4 字节，最大 21 亿多，大多数业务主键和数量字段都够。BIGINT8 字节，分布式场景唯一 ID、雪花 ID、超大金额的累加值，都得用它。
这里有个反面教材：拿int存手机号。手机号在数据库里永远用varchar，因为你在 Java/JS 里拿数字处理容易溢出，而且手机号根本不是“数字”，不需要做加减乘除，它只是一个有格式的字符串。用数字类型存储还可能导致前面有 0 的号码被截断这种低级事故。另一个反面教材是拿int存订单号——订单号是业务序列号，可能蕴含日期/分库分表规则，应该做成varchar或bigint，绝不能图省事就int。
4.2 小数类型：金额必须 DECIMAL，别拿 DOUBLE 跟钱开玩笑
如果你用DOUBLE或者FLOAT存金额，终有一天会被对账折磨死。原因很简单：二进制浮点数无法精确表示大部分十进制小数，比如0.1在二进制里是个无限循环小数，存进去已经产生了误差。当你计算0.1 + 0.2时结果不是0.3，可能是0.30000000000000004。日常展示你看不出来，但累计到几千行订单，流水对不平、总账差几分钱，你找都不知道去哪找。
金额、价格、费率、余额，全部用DECIMAL。你只需要明确DECIMAL(m, d)里m是总位数，d是小数位数。比如订单金额，我一般用DECIMAL(10, 2)，最大能表达 99999999.99，基本满足绝大多数中小业务。如果涉及汇率这种特别需要精度的场景，可以DECIMAL(20, 6)，展示时再四舍五入。不要嘲笑用DOUBLE存金额的做法，很多老系统就是这么活过来的，但他们每年的对账脚本里一定少不了一大堆“抹零”“容差”的脏逻辑。
4.3 字符串类型：长度还是内容，选 VARCHAR 还是 TEXT
我用VARCHAR而不是TEXT的坚持源于一次线上故障。有张资讯表，把正文存进了TEXT，查询时有非常慢的ORDER BY create_time，当时排查才发现TEXT字段作为辅助列，会让 MySQL 使用磁盘临时表，性能直接被拖垮。后来把TEXT拆分到独立的附属表，才恢复正常。所以我的经验是：能用 VARCHAR 的不用 TEXT。VARCHAR 可以指定长度并建立索引，而 TEXT/BLOB 上建索引限制多、效率差。短内容、有索引诉求的，全用 VARCHAR。
VARCHAR 的长度也不是拍脑袋255了事。长度直接关系行大小和索引长度（InnoDB 索引键最长 3072 字节，utf8mb4下一个字符占 4 字节，意味着你varchar(200)的字段建普通索引，200×4 已经 800 字节，还好；如果搞 500 以上，索引就建不上了）。所以总结就是：名称类给varchar(64)足够，编码/序列号给varchar(128)，手机号varchar(20)，邮箱varchar(64)，URL 可以varchar(512)。别有事没事就varchar(2000)，既浪费空间又坑索引。只有一种情况用TEXT：字段内容真的可能超过 64KB 且不需要索引，但一般文章正文也才几十 KB，这种场景极少数。
4.4 时间类型：DATETIME 优先，警惕时区陷阱
时间的存储，很多新手会用字符串varchar存"2024-06-01 12:00:00"，这是最让我头疼的操作。字符串时间无法做范围比较、无法做日期函数运算、也没法排序，查询性能和正确性全是坑。MySQL 里建议用DATETIME或TIMESTAMP。两者区别：DATETIME范围广（1000~9999 年），和时区无关；TIMESTAMP范围到 2038 年，存储跟随时区转换。业务系统我更倾向于DATETIME，因为逻辑简单，不会发生“应用层穿 UTC，数据库转来转去”的错乱。
还有一个“存时间戳”的流派，直接用BIGINT存毫秒数，这在一些大数据系统里看得到。如果你只是普通业务，不建议这样，因为“可读性”归零了，排查问题还得把时间戳转回人类语言。我最后强调一个时区一致性的细节：无论你选哪种类型，全系统要统一同一个时区规则，应用、数据库、日志、消息队列全部对齐到 UTC+8 或者 UTC，不然就会出现“我数据查出来差了 8 个小时”的诡异现象。
5. 主键设计：自增、UUID、雪花，选哪个不只是技术偏好
主键大概是数据库设计里争吵最多的话题，三个阵营各有道理。我的建议往往让人失望：没有银弹，得看你的部署架构和业务规模。但我们可以把每个选项的适用边界讲清楚，让你自己选的时候不用再纠结。
5.1 自增主键：中小系统的默认答案
单库单表、TPS 不高的业务，自增主键几乎是最优解。它的好处是天然有序，InnoDB 是聚簇索引组织，新插入的数据大概率追加到页尾，减少了页分裂，写入性能稳定；主键索引体积小，普通二级索引回表效率也高。还有一个隐含好处，就是当你做“最近新增记录”这类查询时，直接按主键倒序查就行，速度极快。
自增主键的担忧主要有两个：一是并发高的时候，通过auto_increment取号会成为热点，但这在中小系统里远不到瓶颈；二是业务数据可能被遍历抓取，猜测 ID 就能爬走所有数据，敏感业务可以加个随机数或者业务编号兜底。但总体而言，我不建议为了“未来可能分布式”而提前放弃自增主键，业务的复杂度往往是自己的选择，不是技术逼出来的。
5.2 UUID 主键：性能是最大的坑，但某些场景不得不选
UUID 主键最大的问题不在“占空间”，而在“随机性”。B+Tree 的叶子节点按主键有序排列，如果你的主键是随机的 16 字节字符串，那每次插入都可能落在已有页的中间位置，导致大量的页分裂、随机 IO、以及索引碎片化。数据量小的时候无所谓，到了千万级就是一个字：卡。
如果因为业务跨库合并、离线导入、需要“全局唯一”用 UUID，最好做两个优化：一是把 36 位字符串压缩成二进制BINARY(16)，去掉连字符后再存，能省一半多空间；二是可以考虑“类 UUID”的有序方案，比如时间排序的 UUID 变体（UUIDv7），既保持全局唯一又减少随机性，插入性能比传统 UUID 好不少。另外，用 UUID 做业务单据号（展示给用户看）是没问题的，但展示 ID 和主键分开，主键继续用BIGINT，展示用随机业务编号，两头的好处都占。
5.3 雪花算法：分库分表时代的主流选择
当你的系统确定要分库分表，每张分表的自增 ID 会冲突，UUID 随机性的问题又无解，雪花算法就会登场。它的核心是一个 64 位 LONG：1 位符号位（固定 0）+ 41 位时间戳 + 10 位机器位 + 12 位序列号。从设计上，它既保证了全局趋势递增（时间戳在高位），又通过机器位和序列号保证了同一毫秒内的并发不冲突。
但雪花算法不是拿来即用，落地时有两个坑：第一，机器位配置错了或者 ID 生成器重复，就会产生重复 ID，所以你得有完善的启动自检和上报机制；第二，时钟回拨问题——如果服务器的 NTP 对时导致时间倒退，ID 生成器在“下一个时间戳”小于“上一个时间戳”时如果不处理，就会重复发号。常用的措施是“等待回拨完成”或者“借序列号递增”或者“搞一个备用时钟源”，总之，这属于基础设施，值得专门花功夫打磨。
5.4 我的选择路径：三分钟判断法
我每次设计新系统的主键，都按下面的判断路径走：
如果明确单库单表、不需要跨系统合并数据，无脑自增 BIGINT。如果未来可能要分库分表但还没分，也可以用 BIGINT，后面做分片时再换算法；如果系统已经确定了分布式架构，或者业务实体天然就是跨区域的（比如门店、IoT 设备上报），直接用雪花，但必须把“ID 生成器”做成独立组件，而不是每个业务各自实现一套。至于 UUID，我基本只接受它做“非主键业务编号”，做主键的场景很少，除非这个表本质上是“同步合并型”的——比如多终端离线写入后再汇总，这种场景用 UUID 或者基于 UUID 的变体反而省心。
一句话总结：主键的终极目标是“稳定、唯一、趋势递增、占用小”，四选三就不错，四选全是理想世界，但现实中我一般是取“唯一 + 趋势递增 + 小”这三个。
6. 索引设计：提升查询性能的习惯，不是事后的补救
索引设计是否合理，决定了你的数据库是“越跑越快”还是“越跑越慢”。但是我对索引的要求一贯是：要设计，而不是堆砌。很多人的习惯是“查询慢了就加索引”，哪里慢了加哪里，结果索引越来越多、写入越来越慢，查询也没快多少，典型的得不偿失。正确的姿势是在建表阶段就根据“查询模式”规划好索引，而不是等慢查询日志把你打疼了再补救。
6.1 联合索引的顺序：不是想放谁就放谁
联合索引是新手最容易犯浑的地方。比如电商订单列表页，常见查询条件是WHERE user_id = ? AND status = ? ORDER BY create_time DESC。这时候联合索引应该怎么建？大多数人想都不想，直接搞(user_id, status, create_time)就完事。对这个查询来说，这个索引确实能走，因为你条件里前面的列都用上了，排序字段也在索引内，性能最佳。但如果你还有一个高频查询是WHERE status = ? ORDER BY create_time DESC，这个索引就失效了，因为联合索引最左前缀原则要求查询条件必须从第一列开始，你跳过了user_id直接用status，索引就废了。
我的方法是：先收集这个表上所有高频查询，按“等值条件”出现频率排优先级，等值条件最常出现的列放最左边，范围条件（大于、小于）放中间，排序字段放最后面。然后针对极端重要的单独查询再考虑额外建立专有索引，而不是试图用一个大索引满足所有场景。索引设计本质是“用空间换时间”，但空间也不能乱换。
6.2 索引失效的常见案例：隐式类型转换、函数包裹、LIKE 前置通配
设计索引是一回事，让它生效是另一回事。我总结过最常见的索引失效场景，每一个都在真实系统里碰到过。
隐式类型转换：字段是
varchar，你查询时传入的是数字123，MySQL 会自动把字段转换成数字再比较，导致索引失效。常见于电话号、订单号这种 varchar 字段上使劲查的场景。解决办法就是应用层参数一律带引号传字符串。函数包裹列：
WHERE DATE(create_time) = '2024-06-01'，你以为是范围查询，实际上对索引列做了函数运算，索引就失效了。正确写法是WHERE create_time >= '2024-06-01 00:00:00' AND create_time < '2024-06-02 00:00:00'，这样能走索引。模糊匹配前置通配：
LIKE '%手机%'，因为通配符在开头，索引无法从中间开始匹配，只能全表扫。但LIKE '手机%'这种前缀匹配就能走索引。方案是，如果业务真的需要中间匹配，可以上全文索引或者外部搜索引擎，数据库硬扛不是一个正确方向。OR 连接：
WHERE a = 1 OR b = 2，除非两个字段都有独立索引并且优化器能用 index merge，否则很可能全表扫。把 OR 改成 UNION 或者拆成两条 SQL，通常更可控。
6.3 覆盖索引的妙用
不深入了解数据库的人，可能不理解“回表”的概念。简单说，InnoDB 的二级索引叶子节点存的是主键值，你查到二级索引后，还要拿主键再去主键索引里把整行数据捞出来，这个“再捞一次”就是回表。如果你查询的列正好都在二级索引里，就无需回表，这叫“覆盖索引”。
典型例子：一张大表，查询SELECT user_id, status FROM order WHERE status = 1，如果你建了(status, user_id)联合索引，查询需要的两个字段都在索引里，直接就能返回。这在高频统计、列表分页场景很有用。说白了，就是牺牲一点写性能，换取“查询全部走索引”的效果，这笔账绝大多数时候划算。
6.4 别光想着查得快，也要想想写得动
最后一定要泼一盆冷水：索引不是免费的，每个索引在每次 INSERT/UPDATE 时都要同步更新，索引多了写放大严重。一张 1000 万行的表，多加一个索引，插入耗时可能从几十毫秒涨到几百毫秒。所以索引设计必须“克制”：一张表哪怕查询再复杂，我也很少让索引数超过 5~6 个，超过这个数，先回过头检查是不是表设计就没拆干净，或者 JOIN 条件写得太随意。索引不是万金油，它只是对“查询模式”的二次建模，真正决定查询复杂度的还是表结构本身。
7. 高频业务模型的拆解：一对多、多对多、状态机
前面讲的是“原子原则”，这块我想用几个高频业务模型把设计串起来，你会更容易理解那些原则怎么落地。这些模型你几乎在每个系统里都会遇到，掌握了它们，等于拿到了 70% 业务表设计的地图。
7.1 一对多关系：用户-订单、订单-明细的标准拆法
用户和订单是一对多，这是最基础的模型。拆法也很标准：用户的属性留在user表，订单的主信息（订单号、下单用户、总金额、状态、下单时间）放order表，订单里的每个商品明细放order_item表。这里有一个“千万不要做”的操作：把明细 JSON 化存在订单表的一个字段里（items: "[{...}]"）。如果明细永远不会被单独统计、查询、聚合，那也许能撑一阵子；但只要是做电商，明细一定需要被统计（哪个商品卖得最好、哪个仓库出库多少），JSON 存进去就全毁了。宁可拆表多 JOIN，也不要 JSON 一坨。这是我经历过的最痛的教训之一，全天下的优惠券分摊、对账、退款，全建立在明细行的粒度上，你把明细吞进单个字段，就是把自己逼上绝路。
7.2 多对多关系：用户-角色-权限的中间表艺术
用户和角色是多对多，角色和权限也是多对多，标准的拆分是“用户表、角色表、用户角色中间表、权限表、角色权限中间表”。中间表的核心职责就是记录“谁和谁有关系”，所以最少只要两个外键字段。但实际设计时，中间表常常需要“额外字段”。比如用户角色中间表里加一个create_time，权限分配审计要用；加一个source，区分是手动分配还是系统默认。这里我建议两点：一是中间表一定要有独立主键（哪怕你业务上觉得联合主键就够了，独立主键方便后期按单条记录操作）；二是中间表上要建立联合唯一索引，比如unique(user_id, role_id)，防止同一关系被插两遍。
还有一点，很多人觉得“用户-角色”中间表未来不会变化就不重视，实际上权限模型是所有系统里最容易膨胀的部分——今天加个部门角色、明天加个数据权限范围字段，设计时留一点冗余字段空间（但不滥用），比后面一次次 ALTER 要舒服得多。
7.3 状态机：别只存一个字段，记录流转历史更安全
订单有“待支付、已支付、已发货、已完成、已取消”，这个状态流转是典型的有限状态机。表设计上至少要有“状态字段”，用于当前状态的快速检索和判断；如果你要做审计、要做超时自动关单、要排查“这个订单为什么变成取消”，最好再加一张“状态流转记录表”：order_id, from_status, to_status, operator_id, reason, create_time。只存最新状态，时间久了你会完全失去历史；有了流转记录表，问题定位和数据审计都变得清晰。
我见过一个反面设计，把状态存在一个varchar里，还允许NULL，配合一个“上一状态”字段，逻辑混乱到看三个月都理不清。状态机表设计的要点是：当前状态用短整型或短字符串存，流转历史分开记，状态枚举值和业务规则在注释里写清楚。做到这三件事，即便未来状态增加，也就加个流转记录的事，表结构基本不用动。顺带说一句，状态字段默认值要设置，不要允许NULL，否则应用层的判断逻辑会各种绕。
7.4 树形结构：邻接表适合大多数场景，闭包表留给强查询需求
树形结构（分类树、组织架构、菜单树）是另一个高频模型。最常用的方式是“邻接表”：表里一个parent_id指向父节点，简单直观，查儿子容易，但查整棵子树得递归，在 MySQL 8 之前只能多次查询或应用层递归。如果你的树深度很小（2~3 层），邻接表完全够用，查询也不慢。
如果树特别深、或者经常要“查某个节点下整棵子树”，闭包表（closure table）更合适：单独建一张“节点关系表”，存所有“祖先-后代”对，查询子树时一次 JOIN 完成。代价是插入/删除节点时要维护关系表。个人建议是，80% 的业务场景用邻接表就够了，闭包表属于少数高查询强度需求的正解，不要一上来就闭包，过度设计同样会让自己后续维护崩溃。
8. 那些让我反复改表的翻车现场，以及你现在就能避开的雷
前面讲了很多“应该怎么做”，下面用几个我真实的翻车现场来反向说明。这些案例没有一个是高深的理论问题，全是细节，但每个都让我在深夜改数据改到怀疑人生。
8.1 把状态存成字符串，还夹杂着中文
我接手过一个老系统，订单表的状态字段是varchar(20)，存的是"待付款"、"已付款"、"PAID"、"1"这种大杂烩。数据是不同时期不同人写的，查询统计只能 CASE WHEN 一个个清洗。我最终花了一整个迭代，把字段统一改成tinyint枚举，并且加 CHECK 约束（或者应用层白名单校验），才把这坨东西收拾干净。教训是什么？状态字段从第一天就要用短数字或者短英文枚举，而不是中文字符串，中文适合做展示，不适合做存储。
8.2 手机号存 varchar 却允许 NULL
手机号作为登录账号，有人为了“有些人没绑手机号”就把字段设成NULL可空。结果呢？用户表里 NULL 和空字符串混着来，唯一索引对 NULL 不生效——因为 MySQL 的 UNIQUE 索引允许多个 NULL 值，导致同一个手机号可以绑定到多个账号，直接破坏了账号唯一性。正确做法是：真正的手机号字段保持 NOT NULL 且加唯一索引；没绑定的用关联表记录，或者设一个默认不可用的状态来区分。不要拿 NULL 当“没有”的意思，NULL 在不同场景语义模糊，应用的判断逻辑会因此变得复杂。
8.3 订单金额用 DOUBLE，对账对到怀疑人生
这个我前面已经提到过，但值得再说一遍：金额用 DOUBLE 存，看起来“够用”，实际对账时出现 0.01 的差异，你根本说不清是代码 BUG 还是浮点误差。我们用 DECIMAL(10,2) 重构后，一夜之间对账差异全消失了。奉劝各位，涉及钱、分数、费率的字段，没有任何犹豫余地，直接 DECIMAL，这不是性能问题，这是正确性问题。
8.4 一张大表塞太多字段，锁范围变大、缓存命中率下降
很多业务喜欢“宽表崇拜”，所有属性一张表。当表的字段超过 50 个甚至上百个时，问题来了：一行数据体积巨大，InnoDB 一个数据页能装的记录数变少，缓存命中率下降；更新任意字段要拿行锁，锁的就是整行，并发更新不同字段互相阻塞；全表扫描的 IO 开销巨大。解决办法是拆成“核心表 + 扩展表”，核心表存高频、少变、必查的字段，扩展表存低频、多变、大字段。别怕 JOIN，JOIN 的成本通常远低于宽表带来的锁竞争和 IO 放大。
8.5 没有考虑历史数据归档，分区成了事后诸葛亮
前几年有个系统的订单表，没有任何分区，数据 3 年后膨胀到几亿行，日常查询被历史数据拖慢，线上慢查询一堆。后来只能加班做数据归档方案：把老订单迁到历史库，在线库只保留近一年数据。如果当初建表时就按月分区（PARTITION BY RANGE (YEAR(create_time) * 100 + MONTH(create_time))），或者设计好冷热分离的归档策略，根本不会这么痛苦。
我现在的原则是：只要表的数据量会随时间增长，建表时就要把“生命周期管理”纳入设计——要么提前按时间分区，要么明确归档方案，别等把数据库拖垮了才后悔。数据不光是“存下来”，还要想清楚“怎么淘汰”，这是很多新人不会去想的维度。
9. 把设计原则化为日常习惯：一个可执行的检查清单
讲了这么多，估计有些朋友有点晕。最后给一套我自己每次建表都会过的检查清单，项目紧张的时候，照着清单过一遍，至少能挡住 90% 的常见坑。
- 表归属哪个业务域？表名是否遵循统一命名规范？是否加了必要的模块前缀？
- 主键选型是否和目标架构匹配？单库单表优先自增？有没有业务字段误当主键？
- 每个字段类型是否准确？金额/费率是否 DECIMAL？状态/枚举是否短整型？时间是否 DATETIME？字符串长度是否克制？
- 每个字段是否都有注释？状态字段是否完整列出所有枚举值？
- 是否考虑到逻辑删除和统一时间字段？全库是否一套命名？
- 哪些高频查询会打到这张表？联合索引顺序是否按最左前缀原则设计？有没有多余的、查询用不到的索引？
- 是否有需要冗余的聚合字段？冗余字段的更新路径是否明确且可控？
- 树、多对多、状态机等特殊模型是否按对应方式设计，中间表的联合唯一索引有没有加？
- 数据生命周期：这张表要不要分区？需不需要提前规划归档？
- 写完建表 SQL 之后，用 EXPLAIN 跑一遍核心查询，确认索引真的生效，而不是觉得“应该能生效”。
这个清单是我自己整理的，看起来细，但每一条背后都有真实的坑。你真做到每条都有明确答案，这张表基本就是“三年后还能接着用”的样子了。
最后，我还想多嘴说一点。做数据库设计，最关键的其实不是技巧，而是“对数据负责”的心态。你设计一张用户表，意味着未来上千万行用户数据都活在这套结构里；你愿不愿意为一个字段多花两分钟想清楚它的生命周期，决定了一年之后你是在优雅地加字段，还是在狼狈地倒数据。这个选择，每个做开发的同仁都值得认真对待。
