数据库表结构设计规范：字段类型选型与命名最佳实践

数据库表结构设计是每个后端开发都绕不开的基础功。很多人觉得建表就是写几行DDL草草了事，但真正等业务上线、数据量上来之后，才发现当初随手定的字段类型、命名方式带来了多少麻烦。这篇文章结合我这些年接手的各种项目实际经验，把字段设计和命名规范这块一次性讲透，从原则到实操到常见坑位全部覆盖到，看完可以直接套用到自己的项目里。

1. 字段设计规范的核心：打好地基再盖楼

数据库表设计这件事，很多人第一反应是“不就是建几张表吗”。但真正出问题的时候，往往恰恰是因为最开始建表时太随性。字段设计是整个数据架构最底层的地基，地基歪了，后面索引优化、查询调优、业务扩展都是空中楼阁。

我在实际项目里最常见的场景是这样的：需求评审会上业务方说“这个功能很简单，加几个字段就行了”，等真正动手时发现要加的字段类型和现有字段对不上，或者命名风格完全不同，再或者同一个含义的字段在几张表里名字叫法都不一样。这种问题几乎每个项目都会遇到，根子就在于建表初期没有一套可落地的规范，每个人都按自己的习惯来。

1.1 先分清逻辑设计和物理设计的边界

做字段设计的第一步，不是打开Navicat或者PowerDesigner就开始画表，而是先确立逻辑设计和物理设计这两个阶段的关系。逻辑设计解决的是“业务上需要哪些数据、数据之间什么关系”，物理设计解决的是“这些数据在数据库里用什么类型、什么长度、什么约束来存储”。很多新手容易把这两个阶段混在一起，一边聊业务需求一边拍脑袋定字段类型，最后做出来既不像逻辑模型也不像物理模型。

正确的做法是：先通读需求文档或原型，把业务实体梳理清楚。比如做用户信息表，思考“用户”这个实体包含哪些属性，这些属性是单值的还是多值的，哪些属性是可变的，哪些属性是不可变的。逻辑模型阶段不关心字段具体用什么类型，只关心有哪些数据项。物理设计阶段才针对每个数据项确定存储方案。

这样的分离最大的好处是，当底层数据库选型从MySQL换到PostgreSQL时，逻辑模型可以直接复用，物理模型只需按新数据库的规范做类型映射就行。我在一个项目里就经历过从MySQL迁到PostgreSQL的改造，因为当初逻辑设计和物理设计分得清，整个迁移过程几乎没有改表结构逻辑，只是做了一批类型转换脚本。

1.2 设计顺序不可逆，先定实体再定字段

字段设计的实际执行顺序，应该严格遵循“实体 -> 字段项 -> 字段类型 -> 约束条件 -> 备注说明”这个链条。先明确这个表代表什么业务实体，再列出这个实体全部的业务属性，然后才是逐字段确定类型、长度、是否可空、默认值这些物理属性。最后一步但最容易偷懒的是备注说明，很多开发觉得备不备注无所谓，但等三个月后别人接手你写的表时，一行好的字段备注比十行代码注释都有用。

有一个我强烈推荐的做法：在设计阶段就为每个字段准备一个“字段字典”，完整列出字段名、类型、长度、允许值、业务含义、来源系统。这个字典不需要一次性建好，可以在设计过程中逐步完善，但必须在建表时同步完成。后面做数据对账、排查数据问题的时候，字段字典的价值怎么强调都不为过。

1.3 预留扩展性，但别过度设计

设计字段时经常面临一个矛盾：预留多少扩展空间合适？预留太少，后面业务一扩展就要改表；预留太多，又会让表结构臃肿、性能下降。这里的判断标准是：可预测的扩展提前预留，不可预测的扩展不要预留。

可预测的扩展，比如用户实名认证状态，初期可能只有未认证、已认证两种状态，但按行业经验大概率后期会加“审核中”、“认证失败”这些中间状态，这种就可以在字段类型选择上直接预留更宽泛的取值范围。不可预测的扩展，比如用户可能有哪些你根本想象不到的新属性，这类不要去用预留一坨字段的方式瞎猜，而是用扩展表或者JSON字段来解决。

我在一个电商后台项目里见到过最糟糕的“过度预留”实例：有个同事在设计订单表时，为了让表“万能”，加了30个预留字段叫reserved_1到reserved_30，然后业务上线半年后，这些字段一个都没用上，反而让表变得异常笨重，每次查订单都要带着这一大串空字段。这就是典型的过度设计。

2. 字段类型选型实战：每一种类型都有最适合的场景

字段类型选型是整个字段设计规范里最考验基本功的部分。选错类型带来的影响通常不会立刻暴露，但随着数据量增长，性能问题和数据精度问题会逐渐显现。我见过太多因为早期选错字段类型，后面不得不做数据迁移的惨痛案例，做一次全面的字段类型调整，影响面往往涉及所有关联接口和报表，可以说是牵一发动全身。

2.1 数值类型不只是整数和小数那么简单

MySQL的数值类型看起来简单，但实际使用中坑位很多。先看整数类型：tinyint、smallint、mediumint、int、bigint的存储范围和占用的字节数都不一样，选型时不是一看“整数”就无脑用int，而要预估业务上限。

最典型的例子是主键，对于To C业务，用户量百万级以内int完全够用，但如果是消息记录、操作日志这种高并发插入且持续累积的表，主键必须用bigint。我自己接过一个项目，线上交易流水表的主键用的是int，业务跑了三年后主键逼近最大值，最后不得不花一个周末做表迁移，把int改成bigint，停服维护加上数据校验，整个操作耗时十几个小时，还承担了不小的数据风险。这个教训让我之后的主键选型策略变成一句话：凡是只增不减、持续累积的表，主键一律bigint，不差那四个字节。

小数类型的坑更大。数据库里的float和double是浮点类型，存储的是近似值，做金额计算时会出现0.1+0.2不等于0.3这种精度丢失的问题。业务上涉及金额、费率、积分等精确计算的数据，必须用decimal类型。decimal的精度和标度要提前定义好，比如decimal(10,2)表示总位数10位、小数位2位，能够表示的最大金额是99999999.99，是否够用要看业务量级。

还有一类常见的坑是“用int存状态，用int存百分比”。状态字段用int配合注释这种方式本身没问题，但问题在于很多项目里状态值的定义散落在业务代码里，数据库没有校验，代码库里的定义也各有各的版本。这个问题我放到后面“枚举字段”部分细说。百分比字段用int存储时，要考虑清楚是存0-100还是0-10000（百分之一精度），这个约定如果不在设计阶段定清楚，后面做统计报表时各个数据口径不一致会非常折磨。

2.2 字符类型选错，性能差别是数量级的

字符类型最核心的区分是char、varchar、text三者的选型。char是定长字符串，varchar是变长字符串。这里有一个常见的误区：觉得varchar是变长的，所以任何字符串都用varchar最合适。但实际上，char的存取效率比varchar高，因为char类型存储时不用记录额外的长度前缀。所以对于长度基本固定的场景，比如身份证号、手机号、MD5摘要这种，用char反而更合理。

varchar要特别注意长度的设定。我见过不少表里，所有字符串字段一律varchar(255)，这种看似省心的做法实则是隐患。varchar存的是字符数而不是字节数，varchar(255)意味着最多存255个字符。在utf8mb4编码下，每个字符最多占4字节，那么这一个字段最长可能需要约1020字节的存储空间。如果是一次性确定数据长度的字段还好，但如果是索引字段，过长的varchar会导致索引体积急剧膨胀，影响写入性能和查询效率。更严重的是，当varchar长度超过特定阈值时，InnoDB可能将行记录变成溢出页存储，进一步拖慢查询。

实际设计原则是：根据业务真实需要精确计算长度。比如用户名，业务上限制了最多20个字符，就用varchar(50)——注意要预留一些余量给国际化前缀或异常数据，但不要动不动就255。一个几千字的文章内容如果不需要全文索引，可以直接用text，但要注意如果表自带了包含text字段就不是“紧凑型行”，主键索引的效率会受影响。

text字段还有个大坑：不能有默认值。MySQL里给text字段设置默认值直接报错（除非设置explicit_defaults_for_timestamp等特殊场景），这个特性意味着你在设计表时要提前想清楚哪些字段可能是大文本，如果业务上存在“先插入空内容再更新”的场景，text会让插入操作变得更繁琐。

2.3 日期时间类型的选择，时机决定一切

日期时间类型有date、datetime、timestamp三种主要选择。date只存年月日，datetime存年月日时分秒，timestamp也是存年月日时分秒，但两者在存储范围上有区别。datetime的存储范围是1000-01-01 00:00:00到9999-12-31 23:59:59，timestamp的存储范围是1970-01-01 00:00:01到2038-01-19 03:14:07，这就是著名的2038年问题。

timestamp的最大优势是支持时区转换：写入时从当前时区转换成UTC存储，查询时再从UTC转换成当前时区。datetime不支持时区，存进去是什么就是什么。对于需要跨时区的全球化业务，timestamp有天然优势。但要注意timestamp的范围上限问题，如果业务要处理超过2038年的日期，就必须用datetime。

另一个容易忽略的点是“只精确到天”的场景，比如生日、入职日期、合同生效日期这类只用日期不用时间的，直接选date类型，不要用datetime。原因很简单：date类型占用字节更少，而且在做日期比较、日期函数计算时不会因为时分秒字段干扰而产生意外的边界问题。我处理过的一个bug就是从“当天”这个语义上发现的问题：用datetime存入职日期，凌晨秒级数据会导致统计口径混乱，后面改成date类型才彻底解决。

2.4 大字段与JSON字段的取舍

现代数据库一般都支持JSON类型，MySQL从5.7版本开始提供原生的JSON支持。JSON字段确实方便——可以让一张表承载结构不固定的数据，但JSON字段的代价是查询无法走传统索引。虽然MySQL提供了JSON索引优化，但实际使用中，如果业务查询经常需要读取JSON内部的某个键，性能依然远不如将那个键提取成独立字段。

我的建议是：高频查询属性一律独立成字段，低频多变的属性用JSON。举个例子，用户表里姓名、手机号、状态这种查询频率极高的字段必须独立成普通字段；而用户偏好设置、用户自定义属性这种很少用于查询、结构经常调整的，用JSON存储最合适。

大字段方面，text和blob要特别注意不要滥用。如果表的字段数很多且包含多个大字段，InnoDB会在存储时采用溢出页方式存放大字段内容，这样即使只查主键和几个小字段，也可能需要读取额外的数据页，性能影响直接被放大。

3. 命名规范：从表名到字段名的统一艺术

命名规范是数据库表设计里争议最多、也最容易被忽视的部分。我在不同的公司体会过完全不同的风格——有的崇尚“表名要长，含义要全”，有的崇尚“表名要短，代码好写”。其实命名规范没有绝对的对错，核心是“统一”。一个项目里最怕的不是用了某一种风格，而是每一张表都有自己的风格。

3.1 表命名的两种主流风格与取舍

表命名主要分两种流派：一种是单数风格，users表叫user，orders表叫order；另一种是复数风格，users表叫users，orders表叫orders。两种风格都有大量项目在使用。我的建议是：复数和单数本质上不是最关键的，最关键的是和团队的代码风格保持一致。

如果一个项目里ORM框架生成的实体类倾向使用单数，那表名就用单数，这样从表名到实体类的映射没有心理负担。反过来，如果项目从最开始就用复数表名，就统一保持复数。

更重要的规范是表名前缀。在同一个数据库里，如果既有业务表又有日志表、临时表，通过前缀快速区分表用途能节省大量沟通成本。常见的命名前缀有：

• t_前缀：表示业务表，如t_user、t_order
• tmp_前缀：表示临时表，如tmp_export_20250101
• log_前缀：表示日志表，如log_operation、log_login

使用前缀的好处是：第一，代码review时眼见就知道这张表大概是什么用途；第二，运维在排查慢查询时能快速定位到“哦这是日志表，不需要走索引优化”。但要注意前缀不要搞太多种，有个项目里我看到过t_、tb_、tab_、b_、sys_、x_各种前缀五花八门，还不如统一用t_一种来得简洁。

3.2 字段命名七条铁律

字段命名规范我总结了七条铁律，都是踩过坑之后提炼出来的：

第一，一律使用小写字母加下划线分隔。userId这个写法是驼峰式，在Java代码里很常见，但字段名存储到数据库后，MySQL在Windows平台大小写不敏感但Linux平台大小写敏感，如果代码里用userId查询，数据库里存的是user_id，就会出问题。统统使用小写蛇形命名，彻底规避大小写敏感问题。

第二，禁止使用数据库保留字作为字段名。比如name、order、group、desc、level这些词看起来人畜无害，但order是SQL关键字，desc是缩写关键字，直接作为字段名称会让SQL语句非常别扭。解决方案无外乎两种：要么字段名加前缀如order_status、user_name，要么使用反引号包裹，但后者是治标不治本。归根结底设计字段名时避开关键字才是正道。

第三，字段名要能直接反映含义，禁止使用无意义缩写。uid、pwd、nm、dsc这种缩写出了项目组根本没人看得懂，过一个月自己看也费劲。字段名应该在“长度合适”和“含义清晰”之间找到平衡，比如用户名用user_name比uname和username都清晰，创建时间用created_at比create_time和gmt_create更贴合惯例。

第四，同一个含义的词在不同表中必须用同一个英文单词。用户名在t_user里叫user_name，在t_admin里叫admin_name这种情况勉强说得过去，但如果叫name，在t_user表里叫name、在t_student表里叫student_name，就会造成跨表查询时的字段命名不一致问题。所以在项目初始化阶段就应建立“命名词典”——同一个中文含义对应固定的英文字段名，新表设计时查词典复用，不再创造新词。

第五，不用词义过于宽泛的字段名。比如status这个字段名放在订单表里，大家还能猜到是订单状态，但如果放在一个综合业务表里，就完全不知道这个状态是“审核状态”还是“支付状态”还是“发货状态”。更精确的做法是，将状态的核心业务修饰词前置，如order_status、pay_status、audit_status。这一条直接关系到字段自解释性——拿到字段名不需要看备注或查代码就知道这个字段管什么。

第六，布尔字段的命名要有统一的约定。布尔字段有is_enabled、is_deleted、has_xxx这几种常用风格，项目里选定一种就全部统一。注意is前缀有个众所周知的坑：MyBatis等框架在映射Boolean类型到Java实体时，会默认把is_enabled映射成enabled而不是isEnabled，容易导致各种踩坑踩到怀疑人生。为此，很多团队干脆约定不使用is_前缀，改用enabled、deleted、published这类形容词或过去分词做布尔字段名，避免框架映射问题。

第七，日期时间字段的命名要区分出授时语义。created_at/updated_at几乎是行业标配，但order_time这种表述到底是下单时间还是支付时间还是发货时间，潜意识里就会有歧义。更好的做法是把这个时间对应的业务动作直接放进字段名，比如order_created_at、paid_at、shipped_at、completed_at，一眼就能看懂。如果需要存“操作人”，对应地就是creator_id、operator_id、approver_id，按照动作严格对应，时间和操作人字段要成对出现。

3.3 索引命名和约束命名也别敷衍

索引、约束的命名同样值得花点心思。主键约束一般是表名加_pkey这样的后缀，唯一索引用uniq_前缀加字段名，普通索引用idx_前缀加字段名。

从可运维性来看，索引命名清晰的意义在于：当线上出现慢查询，DBA拿到慢日志里的索引名，能直接通过索引名猜出索引建立在哪些字段上，不用再连上数据库去查表结构。比如idx_user_name这个索引名，一眼就知道是用户名字段上的索引。如果索引名是随便生成的idx_1、idx_2，排查效率会大打折扣。

还有一个细节：当需要删除某个索引时，如果索引名包含了字段含义，就能精准定位，避免误删其他索引。索引名称的唯一性在MySQL中是在表级别生效的，同一张表里索引名不能重复，不同表可以有同名索引，所以保存好索引字典，建议在表设计文档里把索引清单也一并记录清楚。

4. 用户信息表设计实战：把规范落到一张具体的表上

理论说再多，不如动手做一张完整的表。这里就以最常见的用户信息表为案例，完整演示一遍从需求分析到字段设计到最终落地DDL的全过程。这也是网上那个热搜“第1关：数据库表设计 —— 用户信息表”背后真正想考察的能力。

4.1 用户信息表的需求分析

先梳理用户信息表需要承载哪些数据。一个常规的业务系统里，用户实体必然包含：

• 用户的唯一标识，即主键
• 用户在业务侧的标识，如用户名、昵称
• 联系方式，如手机号、邮箱
• 认证信息，如密码摘要、盐
• 基础属性，如性别、生日、头像
• 账户状态，如是否锁定、是否可用
• 审计字段，如创建时间、更新时间、创建人、更新人
• 逻辑删除标记

这个列表看着全面，但核心原则是：一张表只存这个实体自身的属性信息，其他和用户有关系的业务数据，比如用户的订单、用户的地址，都应该放到对应的订单表、地址表里去，而不是冗余在用户表里。这个判断标准用起来很简单：如果一个字段要体现“用户在某个业务动作中产生的数据”，就不属于用户表，属于那个业务动作的表。比如“用户最近一次下单时间”这个字段，初看起来是在描述用户，但实质是用户与订单的关系，不应该放进用户表，而是通过订单表来获取。

4.2 全字段明细与类型选型推演

基于上面的分析，逐步定下用户信息表的字段设计。整个过程我建议在PowerDesigner这类建模工具里画物理模型来做，体验比直接写DDL好得多，字段之间的相对位置调整非常直观，而且能直接生成DDL脚本。

先看主键字段：

• id：bigint unsigned，自增主键。为什么不选int？前面已经说过，用户表是典型的只增不减的表。哪怕现在只有几万用户，直接把bigint定好。主键字段虽然叫id很常见，但有些团队喜欢用user_id，这个看规范统一，这里用id更通用。

再看用户名与认证字段：

• user_name：varchar(50)，用户登录名，是用户唯一性标识，建议加唯一索引。注意这里不建用户名字段时用varchar(255)，50已经足够覆盖绝大多数业务场景的用户名长度。如果业务有国际化需求，再根据实际规则调整长度，但不要一上来就非常宽。
• password_hash：varchar(100)，密码哈希值。之前看到很多表用varchar(32)来存MD5的密码摘要，但现代密码存储推荐使用bcrypt或者argon2算法，这类算法生成的哈希串长度通常在60位以上，所以预留到100比较合理。这一行中间那个下划线是一种通用习惯，表示存储的是某种摘要/加密后的结果。
• password_salt：varchar(32)，密码盐。盐值通常随机生成，用32位的字符串存入比较稳妥。
• phone：char(11)，手机号。这里用char而非varchar，因为手机号长度固定为11位，用定长char存储效率更高。注意手机号未来可能存在国际化的可能性，比如e.164格式带+86前缀，那长度就要重新评估。如果不确定就varchar(20)，同时兼顾后续扩展。
• email：varchar(100)，邮箱地址。长度给到100主要是考虑不同邮箱服务商和域名长度，常规的邮箱50以内就够，但偶尔会遇到较长的域名。

再看用户基本信息和状态：

• nickname：varchar(50)，昵称，允许为空。很多系统里用户可以不设置昵称，此时可以回退到user_name来展示。
• gender：tinyint，性别，0未知、1男、2女。这个问题我经常被问到“用不用枚举类的字符串存性别”。这里用tinyint加代码注释，数据库比较轻量，业务代码里做一层转换就行，但前提是项目里必须有完善的枚举管理机制。后面会专门讲到枚举字段的注意事项，这里先按下不表。
• birthday：date，生日，只到日期即可。
• avatar_url：varchar(255)，头像地址。如果项目里用了对象存储，存的是URL。因为对象存储的访问地址长度有时会超过255，所以如果需要预留更多可以varchar(500)，但这个长度对InnoDB行格式不友好，实际多数场景255够用。
• status：tinyint，账户状态，1正常、2锁定、3禁用。网上很多教程喜欢用is_active来表示激活与否，但从业务扩展来看，账户状态往往不只是“激活/未激活”二态，还可能有“冻结”这种异常态，所以直接用status配合注释的方式更灵活。如果想要彻底规避状态歧义，可以拆成多个布尔字段，比如is_locked、is_disabled，选择性很强。这里强烈不推荐用两个布尔字段来表示“锁定且禁用”这类叠加状态——布尔字段只有0和1，本质上是存不了多状态的。
• last_login_at：datetime，最近一次登录时间。这个字段常用且经常会被漏掉，但设计时要想清楚它代表“最近一次成功登录时间”还是“最近一次登录尝试时间”，建议在字段备注里写明。
• last_login_ip：varchar(45)，IP地址。IPv6的地址最长是45个字符，所以varchar(45)，不要用varchar(20)，更不要用int来存IP——因小失大，别省那点存储。

最后是审计字段：

• created_at：datetime，创建时间。
• updated_at：datetime，更新时间，每次更新自动修改。
• created_by：varchar(50)，创建人，存用户的ID或系统标识。这里如果业务上有明确的“操作人ID”，可以使用bigint，但常见做法是varchar，因为可能是系统触发或者admin，可读性更强。这个可以按团队习惯统一。
• updated_by：varchar(50)，更新人。
• is_deleted：tinyint，逻辑删除标记，0未删除、1已删除。

4.3 在PowerDesigner里落地物理模型

PowerDesigner是数据库设计领域的老牌工具，虽然界面有些年头了，但胜在功能完备，而且是很多企业规范里明确要求的建模工具。用PowerDesigner设计用户信息表的步骤并不复杂：

第一步，新建Physical Data Model，选择数据库类型为MySQL 5.0或对应版本，注意版本选择会影响生成DDL的语法和类型映射。

第二步，新建Table，命名为t_user，依次填入上面梳理出的所有字段。每个字段要同时设置好数据类型、是否必填、是否主键、默认值和注释。PowerDesigner的字段面板操作很简单，关键是手动为每个字段编辑好Comment，后续生成DDL时注释会自动带过去，这一点对于维护数据字典非常重要。

第三步，建立索引。在Table的属性窗口切到Indexes页签，为user_name建立唯一索引unique_index_user_name，为phone建立唯一索引unique_index_phone，为status创建普通索引idx_status。这里注意唯一索引的作用是防止业务代码并发插入相同用户名，数据库层面做一个兜底，这是很常见且必要的操作。

第四步，生成SQL脚本。在PowerDesigner菜单里选择Database -> Generate Database，勾选生成创建表的脚本，一个全新的用户信息表物理模型就落地了。生成的DDL还可以导出为sql文件，提交到Git仓库作为数据库变更记录。

PowerDesigner设计一个单独的数据库表E-R示例本身就是很多教材里的经典练习，核心目的就是让大家通过实际动手把上面的规范和操作串起来。做完一张表后，对你的理解提升是看十篇文档都换不来的。

4.4 用户信息表完整DDL参考

前面用PowerDesigner设计的物理模型，生成的DDL最终效果如下，可以直接跑在你的MySQL 5.7及以上版本里：

CREATE TABLE `t_user` ( `id` bigint unsigned NOT NULL AUTO_INCREMENT COMMENT '主键', `user_name` varchar(50) NOT NULL COMMENT '用户登录名', `password_hash` varchar(100) NOT NULL COMMENT '密码哈希值', `password_salt` varchar(32) NOT NULL COMMENT '密码盐', `phone` char(11) NOT NULL COMMENT '手机号', `email` varchar(100) DEFAULT NULL COMMENT '邮箱', `nickname` varchar(50) DEFAULT NULL COMMENT '昵称', `gender` tinyint NOT NULL DEFAULT '0' COMMENT '性别：0未知，1男，2女', `birthday` date DEFAULT NULL COMMENT '生日', `avatar_url` varchar(255) DEFAULT NULL COMMENT '头像地址', `status` tinyint NOT NULL DEFAULT '1' COMMENT '账户状态：1正常，2锁定，3禁用', `last_login_at` datetime DEFAULT NULL COMMENT '最近一次登录时间', `last_login_ip` varchar(45) DEFAULT NULL COMMENT '最近一次登录IP', `created_at` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间', `updated_at` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间', `created_by` varchar(50) DEFAULT NULL COMMENT '创建人', `updated_by` varchar(50) DEFAULT NULL COMMENT '更新人', `is_deleted` tinyint NOT NULL DEFAULT '0' COMMENT '逻辑删除：0未删除，1已删除', PRIMARY KEY (`id`), UNIQUE KEY `uniq_phone` (`phone`), KEY `idx_status` (`status`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin COMMENT='用户信息表';

这段DDL里有两个细节值得展开说一下。

第一是排序规则utf8mb4_bin。utf8mb4_bin是二进制排序规则，和默认的utf8mb4_general_ci / utf8mb4_0900_ai_ci相比，它的比较是区分大小写的，而且按二进制值排序更加确定。对于用户名这种字段，使用_bin排序规则可以避免MySQL在比较时对大小写不敏感导致的用户唯一性冲突。举个例子，如果使用utf8mb4_general_ci，'Tom'和'tom'会被认为是重复的用户名；使用utf8mb4_bin则可以区分。具体用哪种取决于你的业务需求，但要注意排序规则会同时影响唯一索引和普通索引的匹配规则，这个一旦建表后想改、对存量数据的影响非常大。

第二是逻辑删除字段is_deleted。逻辑删除本身是一个取舍的结果：保护数据不物理删除，方便审计和回收，但代价是每次查询都要带上is_deleted=0的条件。这个字段有好几个注意点：一是要有默认值并加注释标明0和1的含义；二是唯一索引要小心逻辑删除的数据占用唯一键——比如phone上有唯一索引，当用户注销删除了逻辑记录后，再注册同一手机号会出现唯一键冲突。解决办法是：要么在注销时把phone改成一个带时间戳的假号码，要么把唯一索引改成复合索引（phone, is_deleted）。这些都必须在设计阶段想到。

5. 公共字段与保留字段的设计智慧

公共字段是每张业务表都会遇到的问题。很多团队在建表时完全靠各个开发临时临场发挥，今天这个表加了created_at和updated_at，明天那个表忘了加create_by，后天又是另一个表把is_deleted写成了deleted_flag，整个数据字典乱得难以收拾。所以公共字段必须在组织层面定出一套标准，所有新表统一套用。

5.1 公共字段的标配清单

每个团队可以为自己的业务定制公共字段集，但通常标配包含这么几类：

• 主键字段：idbigint unsigned auto_increment
• 时间审计字段：created_at、updated_at
• 操作人字段：created_by、updated_by
• 逻辑删除标记：is_deleted
• 版本号字段：versionint，用于乐观锁控制

版本号字段可能被很多团队忽略，但如果是修改频繁、并发冲突风险高的业务表，版本号几乎是必备的。每次更新时带上version条件，update where id=? and version=old_version，更新成功version加1，这个做法可以有效避免并发覆盖问题。订单、库存这类高频更新的表尤其需要。

公共字段的维护有两种方式：一是直接在每个表的DDL中写死，这就是最常用的方式；二是通过数据库层面的模板生成工具来自动带上，每次建表时顺手加进去即可。但公共字段不一定都要交给每个开发来手工写，团队内可以统一一套建表模板，所有人在这个模板基础上做业务字段扩展。

5.2 主键策略：自增主键还是业务主键

主键设计是整个表结构里最牵动全局的决策。最常见的两种做法是自增主键和UUID主键，各有各的适用场景。

自增主键的优点：写入性能好，因为InnoDB中主键是聚簇索引，自增主键在插入时是顺序追加，页分裂概率最低；占用空间小，对二级索引的大小也有利。缺点是：数据迁移时可能会发生主键冲突，需要做映射；业务数据会暴露规模量级，例如用户id是10086，基本能猜到用户大概刚过一万。

UUID主键的优点：分布式的场景下可以在多个节点生成，不依赖数据库自增序列；数据不会暴露业务规模。缺点是：无序性导致聚簇索引页分裂频繁，写入性能严重下降，特别是数据量大之后这个问题极其明显。UUID是36个字符的字符串，如果直接存成varchar(36)，二级索引的存储空间也大得多。

现实的折中方案是：单库单表场景直接用自增主键；分库分表场景用雪花ID或类似方案（分布式ID生成器），既保序又有全局唯一性，同时避免了UUID在存储性能上的劣势。从查错角度来说，雪花ID比UUID短不少，对索引更友好。至于业务主键（比如用身份证号、手机号直接做主键），建议不要这么干。业务主键的问题在于业务规则一旦变化，比如手机号换了，主键就跟着变了，主键关联的外键数据全部要跟着改。正确做法是物理主键用自增id，业务唯一性通过唯一索引来保证。

5.3 预留字段到底该不该用

关于预留字段，我的观点非常明确：不要用reserved_1这种万能字段。字段的语义一旦預留得不够精确，要么变成垃圾数据收集器，要么沦为空列浪费存储。更好的做法是：如果无法确定未来要扩展什么，就什么都不预留，等真正需要时再通过ALTER TABLE加字段。MySQL 8.0支持INSTANT算法加字段，秒级完成，这种操作已经不是什么伤筋动骨的事了。

与其预留无意义字段，不如留好“结构层”的扩展机制。比如用扩展表和JSON字段来应对不确定的属性需求，这个在前面字段类型选型部分已经说过了。扩展表的方式比较重一点，但每个语义都是精确的；JSON字段比较轻，适合属性零散不固定的场景。

6. 常见问题与踩坑经验速查

这一部分我把这几年在各种项目里实际遇到的字段设计问题汇总成一个速查表，很多坑如果不是亲身踩过，看文档根本看不出来。建议收藏备用。

6.1 高频问题速查表

上面每一项的背后基本都有血淋淋的线上事故或至少是查数据查到怀疑人生的经历。比如手机号用int存，业务上线后某用户手机号是13812345678，存进去变成小数点，导出数据一堆问题；时间字段用字符串存，报表系统每次都要做字符串转换，性能差了一大截还容易踩格式坑；逻辑删除配合唯一索引冲突这个问题，初期用户量不大可能遇到不多，等上线一段时间大量注销用户开始复用手机号时才暴露，改起来真的要命。

6.2 排查线上问题的三板斧

当线上遇到与字段设计相关的数据问题，我习惯按这个顺序排查：

第一，先看字段设计本身。如果某个字段存了预期之外的数据，优先怀疑建表时的约束没到位。比如应该NOT NULL的字段允许为空、应该加唯一索引的字段没加、应该用decimal的地方用了float，这类问题在数据量小的时候不痛不痒，到了线上会以各种奇怪的方式显现。

第二，再看代码写入入口。锁定是哪个接口或哪个写入任务写入的数据。如果入口代码里对字段做了类型转换但没有做越界保护，就很容易把超出数据库字段长度的数据截断。

第三，最后看数据流转链路。尤其是数据从消息队列或者同步任务批量写入时，常常会有脏数据源头的问题。此时，一张字段备注完整的表就格外重要——你得能看懂每个字段原本的业务含义，才知道某个异常值到底“该不该出现”。

6.3 几条我认为最值得分享的独家经验

最后分享几条我觉得真正值钱的实操经验，这些在教材里很难找到。

第一，在任何表上都尽量带上version字段。有些纯只读表、字典表可以不加，但只要是可更新的业务表，加上version字段几乎没坏处。就算现在没有乐观锁需求，后面接缓存、做分布式架构时，version字段都是非常有价值的基础设施。

第二，枚举字段不要只靠数据库注释来维护含义。更好的做法是建立枚举字典表，或者至少把枚举定义统一收敛到代码中的一个枚举类，并通过数据库校验约束（比如MySQL 8.0的check约束）确保写入值不会超出枚举范围。数据库的注释是不够的——注释永远不会报错，也不会拦住非法数据，只能供人查阅。

第三，对“万能字段”保持警惕。如果一个字段设计的初衷是“既可以存这个又可以存那个”，那它最终很可能什么都没有正确地存好。与其设计万能字段，不如把每个字段的边界定义清楚，数据质量才是后续所有数据处理工作的根本。

从最开始的那次大迁移，到后来每一次新业务建表，我越来越觉得：字段设计做得好不好，短时间内看不出什么差距，但时间线拉长后，一个字段设计扎实的数据库和一个字段设计随意的数据库，在数据质量、开发效率、排障速度上的差距是数量级的。数据库表设计这个系列我会继续写下去，后续准备聊一聊索引设计规范、SQL写法规范、大表分库分表经验这几个方向。如果你正在做系统建模或者准备对老系统的表结构做一次规范治理，希望这篇能成为你的参考手册。