数据库表设计40条规范：从命名到索引的实战指南

2. 数据库表设计，本质是先想清楚业务，再动手建表

做了十几年后端开发，我接手过的数据库表少说也有上千张。这些年踩过的坑、替别人擦过的屁股，让我越来越确信一件事：数据库表设计规范不是哪家公司的内部规定，而是一套能让后续所有开发、运维、数据分析环节少流血的通用底线。

很多团队的表结构长得五花八门，有的用拼音缩写命名字段，有的把状态字段设计成字符串存中文字，有的索引用得乱七八糟，主键用UUID字符串直接铺满全表。表面上看这些表都能跑，等业务复杂到一定程度，慢查询、死锁、数据不一致、迁移困难，全来了。这时候再返工，代价远比你想象的大。

我整理这套40条数据库表设计规范，不搞虚的，全部来自实际项目和真实场景。按照这套规范来设计，至少能保证三件事：一是别人接手你的表不用猜；二是业务迭代时表结构改动成本可控；三是数据量上来之后，性能和稳定性不会成为瓶颈。适合刚入行的后端开发、从单机项目走向团队协作的工程师，以及所有需要设计数据模型的从业者参考。

这套规范没有按优先级排序，每一条都很重要。我尽量用说人话的方式解释每条规则背后的原因，附上反例和实际建议，方便你对照自己的表检查。

2. 设计整体思路：40条规范是怎么分类的

2.1 先从最容易扯皮的命名规范说起

命名是表设计里最容易被忽略、后期又最让人头疼的部分。我见过一个项目，订单表叫order，用户表叫user，看起来挺正常，结果商品表叫goods_info，订单明细表叫orderdetail，支付记录叫pay_log，四个表四种风格，连字段名都各写各的。每次写SQL统计都要查一遍表结构，纯属浪费时间。

命名规范不只是好看，它直接影响检索效率、团队沟通效率和代码生成工具的匹配度。规范的命名让新成员三天就能上手业务，不规范的命名能让人三周都理不清关系。所以第一类规范先解决照章说话的问题。

2.2 字段和类型是表设计的物理基础

字段是表的骨架，类型是字段的骨架。类型选不对，轻则浪费存储空间，重则产生精度丢失、隐式转换导致索引失效、排序结果错误等诡异问题。比如金额字段用float，你以为存的是99.9，查出来可能是99.90000000000001。这种问题在报表对账的时候简直能让人崩溃。

数据类型的规则本质上是在回答三个问题：这个数据到底长什么样？取值范围有多大？会不会参与计算和比较？想清楚这三个问题，类型自然就能选对。

2.3 主键、索引、范式与冗余，衡量性能与一致性的砝码

主键和索引决定了查询快不快，范式和冗余决定了数据一致性和开发成本之间的平衡。这部分最考验功底，也是面试官最爱问的东西。网上关于B+树、聚簇索引的文章一搜一大把，我不重复那些理论，只讲落地时的选择和取舍。

2.4 通用字段和设计习惯，决定系统的可维护性

最后一块是通用字段，比如创建时间、更新时间、逻辑删除标记、版本号。这些字段不是业务必须的，但几乎每个业务表都需要。加不加这些字段，短期内看不到差别，等出问题需要回溯数据、排查线上故障、做增量同步时，才能体会到什么叫“当初多写一行字段，今天少熬一宿夜”。

下面进入正题，40条规范逐条来。

3. 40条规范逐条拆解

3.1 命名规范（第1条到第12条）

规范01：表名统一使用小写字母，单词之间用下划线分隔。

MySQL在Linux下默认区分大小写，在Windows下不区分，如果代码里一会儿写Order一会儿写order，换环境部署就会出现莫名其妙的表找不到错误。下划线分隔是为了可读性，orderdetail完全不如order_detail直观。另外表名尽量用复数或不带复数意义的单词，避免同一张表有时候叫user有时候叫users的问题。

规范02：表名前缀按业务模块划分，避免跨模块重名。

比如订单模块用odr_开头，用户模块用usr_开头，商品模块用prd_开头。这样做有三个好处：一看表名就知道属于哪个模块；防止不同模块出现同名表；在数据库客户端里可以按前缀快速筛选。缺点是表名会变长，但这点长度对数据库来说毫无压力。

规范03：字段名使用业务含义明确的英文单词，禁止拼音和缩写混用。

字段名设计最重要的是让“看的人一眼就懂”，缩写虽然在开发时省了几个字母，但后续维护的人可能要猜半天。我见过一个表里username写成yhm，create_time写成cjsj，这种设计基本等于给后来人挖坑。字段名尽量用完整的英文单词，实在长的省略元音，但必须保证团队内部有统一缩写词典。

规范04：字段名遵循小写+下划线，与表名风格保持一致。

原因和规范01一样。

规范05：字段命名名词化，不要包含动词。

比如create_user表示创建人，比creating_user正常。字段只描述数据是什么，不描述操作过程，语义更清晰。

规范06：逻辑删除标记统一叫deleted，不用is_delete或del_flag等变体。

统一逻辑删除标记命名这事，起初我是吃过亏的。以前项目里有人写is_deleted，有人写del_flag，还有人写status=0表示删除，统计的时候一条条核对条件，后来干脆在代码里做了一个工具类统一拼条件，但表格不统一还是容易出错。后来我们规定所有表逻辑删除字段都叫deleted，字段类型tinyint，0为未删除，1为已删除。规则越简单，出错概率越低。

规范07：主键统一叫id，类型为bigint，所有表约定一致。

统一主键命名为id，好处很多：MyBatis等ORM框架默认能识别；代码生成器可以少配置；多表Join的时候不用纠结用哪个字段做主键。类型用bigint是因为int最大只有21亿多，对很多业务来说不够用。id不用无符号int这种偏门写法，直接上bigint，省得以后数据类型撑爆再改。

规范08：创建时间字段统一叫create_time，更新时间统一叫update_time。

时间字段的命名五花八门是重灾区，有人叫gmt_create，有人叫created_at，还有人叫crt_tm。统一成create_time和update_time，所有表都这么叫，代码里可以做通用处理。比如插入时统一填充当前时间，更新时统一更新update_time，不需要每张表单独写一遍逻辑。

规范09：索引命名格式统一为idx_字段名，唯一索引统一为uk_字段名。

这个规范直接决定了DBA帮你排查慢查询的效率。一张几百行的小表，建了五六个idx_xx_1这种名字的索引，完全不知道是给哪个查询用的。索引命名为idx_字段名1_字段名2，唯一索引为uk_字段名，一眼就能看出索引覆盖了哪些列。如果一个索引覆盖了多个字段，按字段顺序拼在名字里，比如idx_user_id_status。

规范10：外键约束名使用fk_开头，但建议尽量不使用物理外键。

外键命名规范还是要定的，防止有些人随手起个名字。但强烈建议不要开启数据库物理外键约束。物理外键会带来几个问题：插入子表记录时必须先查父表，影响写入性能；高并发下外键检查可能造成锁竞争；跨库分表后外键根本没法用。外键关系通过代码逻辑维护，配合索引保证查询性能，这是互联网公司的通用做法。规范10：外键约束名使用fk_开头，但建议不要使用物理外键，用逻辑外键。

规范11：布尔类型字段使用is_开头，如is_admin、is_deleted，类型统一为tinyint(1)。

数据库的布尔类型看似好用，实际不同数据库实现差异很大。MySQL没有真正的boolean，用的是tinyint(1)；Oracle没有布尔类型，要用number(1)替代。如果代码里写着各种自定义类型，跨数据库同步时就麻烦。统一约定：布尔字段以is_开头，类型tinyint(1)，只允许存0和1。

规范12：日期字段统一使用datetime类型，禁止使用字符串存储日期。

这一点绝对是血泪教训。有人图省事把日期直接存成varchar，比如“2024-03-15 14:30:00”，表面上看着挺正常，等你要按日期排序、按月分组统计、做时间范围查询时就会知道多痛苦。字符串比较大小是按照字典序，datetime比较是按照时间语义，两者结果可能不一致，而且字符串没法用日期函数，索引效率也比不上datetime。

3.2 字段类型规范（第13条到第22条）

规范13：整数类型根据取值范围选择tinyint、smallint、int、bigint，用最小满足需求的类型。

这条规范解决的是存储空间和性能问题。数据库是按页存储的，跟内存一样，页里能塞多少行数据，直接决定了查询时一次IO能加载多少条记录。同样一张1000万行的表，如果状态字段用int存，占用4字节；用tinyint存，占用1字节，单行数据变短，一个数据页能容纳更多行，全表扫描的IO次数就少。虽然后期都可能加内存和缓存，但好习惯成本几乎为零。

规范14：金额相关字段统一使用decimal，禁止使用float和double。

承接我前面说的例子，float和double是浮点数，在计算机里是近似值。你往数据库里存99.9，再把它查出来，得到的可能是99.90000000000001。对订单、账户、佣金这类涉及钱的字段，绝对不能出现这种误差。decimal是定点数，按十进制存储，可以精确表示小数。定义的时候要指定精度，比如decimal(10,2)表示总长度10位、小数部分2位，最大能存99999999.99，绝大多数业务场景够用了。

规范15：字符串类型优先用varchar，只有在明确固定长度时才用char。

varchar是变长字符串，按实际内容长度存储，char是定长字符串，比如char(20)不管你存1个字符还是20个字符，都占用20个字符的空间。char的优点是没有存储长度标识，某些边界情况下性能稍好，但绝大多数业务字段都是变长的。用户名、手机号、地址，哪个是绝对固定长度的？手机号倒是固定11位，但用户可能输入加区号的。统一用varchar，省空间，避免多余的空格问题。

规范16：varchar的长度不要滥用，能满足需求即可，避免一个字段定义varchar(5000)。

varchar长度开太大有两个问题。一是如果定义了varchar(5000)，虽然变长存储不会真的占用5000字符的空间，但索引的时候限制很多，超过长度限制无法建前缀索引，或者需要按前缀长度建。二是排序的时候可能触发临时表的磁盘存储，导致慢查询。通常业务表中，普通描述类字段建议控制在255以内，大段文本使用text类型，并且尽量不要直接在业务表里存，考虑放到对象存储或者拆到单独的附表。

规范17：文本内容超过255字符的，使用text类型，并单独拆表或使用ES等检索方案。

一张表里有text字段其实问题不大，真正的问题是：text字段不能有默认值；text字段参与排序或分组时要格外小心，因为会造成临时表；如果text字段很大，select *会把大量无关的数据加载到内存里，拖慢查询。更糟的是一张表里有多个text字段，每行数据都可能占用好几KB，导致数据页能容纳的行数急剧减少。文本内容较长且需要检索的，要么拆到单独详情表，要么直接进Elasticsearch、全文索引方案。

规范18：表必须包含主键，且主键保持简单。

没有主键的表是极其危险的存在：无法定位到具体记录、binlog同步无法可靠执行、数据去重无从谈起。主键还应该简单，单列主键优于联合主键，因为InnoDB的聚簇索引结构就是按照主键组织的，主键越短，二级索引占用的空间也会越小。如果一张表确实找不到自然主键，就加一个自增的物理主键，业务上再用其他字段做唯一约束。物理主键只负责稳定标识记录，不承担业务语义。

规范19：尽量避免使用联合主键，需要联合唯一时使用独立主键+唯一索引。

联合主键最麻烦的地方在于：如果业务变化，原来作为主键的组合字段不能用了，你想改主键定义，成本极高；而且联合主键会让所有二级索引的体积都变大。正确的做法是用自增id做物理主键，同时在业务字段上建唯一索引，保证业务上不重复。这样既满足了唯一性要求，又保留了对主键的完全控制。

规范20：主键不推荐使用UUID字符串，优先使用自增整型或分布式ID。

UUID做主键最大的好处是全局唯一、无需连库生成，缺点也很致命：字符串类型占空间，比bigint大很多；随机生成导致无序，插入时索引页频繁分裂，写入性能差，页分裂还会产生大量碎片。如果担心自增id被人遍历爬走，可以换雪花算法生成分布式ID，雪花ID是整型且趋势递增，既保证了唯一性，又不破坏索引性能。总之：主键必须整型、尽量递增，这是InnoDB表性能的底线。

规范21：所有字段必须显式指定默认值，不允许空着不写。

让字段有默认值，代码插入时可以少写很多字段，更重要的是防止出现意想不到的NULL值。很多人说“这个字段不需要默认值”，等数据进来后才发现一堆记录这个字段是NULL，后续统计要用group by，NULL字段根本不参与分组，结果就错了。一般的做法：整型默认0，字符串默认空字符串，时间字段默认当前时间或NULL根据业务定，布尔默认0。

规范22：字段设计尽量避免NULL，无法避免时用特殊值替代。

NULL是一种很特殊的“值”——它不是0也不是空字符串，而是“未知”。查询、Join、聚合函数、索引，NULL和普通值的逻辑都有细微差别。比如count(字段)只会统计非NULL的行，如果你期望它统计所有行，结果就是错的。能用0、空字符串、-1这些特殊值表达的，不用NULL。实在要表达“未知”，再加一个meaning字段说明特殊值的含义。

3.3 结构设计规范（第23条到第33条）

规范23：每张表都保留create_time、update_time两个时间字段。

这是我跟很多后端同行反复强调的一点。哪怕今天业务用不上，也强烈建议加上。它的价值在排障的时候体现得最明显：数据对不上账了，排查某个订单什么时候创建、什么时候更新，有这两个字段就能直接定位，没有就只能干瞪眼。实现上也简单，代码在插入和更新时自动填充，或者数据库层面用default current_timestamp和on update current_timestamp。

规范24：每张业务表都要有deleted字段（逻辑删除标记）。

物理删除数据的坏处是：删了就没法恢复记录；可能触发外键约束或级联删除错误；业务上想查“曾经存在过什么”做审计，无从下手。逻辑删除字段deleted配合查询条件，所有的select语句都要加上where deleted=0的限制。如果担心忘记加条件，可以在ORM层的公共查询基类里自动拼接。这就是牺牲一点查询性能换数据安全，值。

规范25：核心业务表建议增加version字段，用于乐观锁控制并发。

并发更新时，常见问题是两个请求同时读到同一行数据，各自修改后提交，后提交的覆盖先提交的，导致更新丢失。解决方案之一就是乐观锁：表里加version字段，更新时set version = version + 1 where id = #{id} and version = #{oldVersion}，如果影响行数为0，说明版本不对，操作失败，提示用户重试。version字段类型用int，初始值0，每次更新加1。

规范26：设计表结构时必须预留创建人、更新人字段，方便问题追踪。

这些字段一般叫create_by、update_by，存用户ID或用户标识。它的作用是在业务出现争议或数据异常时，快速定位是谁在什么时间做了什么操作。如果你有审计合规的需求，还可以考虑更完整的审计日志表，但即便不做审计，create_by和update_by也建议加上，成本很低。

规范27：状态字段使用tinyint或varchar，不要使用中文或英文单词直接存。

状态字段存中文“已支付”，存英文“PAID”，最大的问题是对代码不友好，而且可扩展性差。后来加了一个状态，要么改表结构，要么用一段很长的映射逻辑处理。建议：状态字段统一用数字编码，比如0、1、2、3，在代码中定义枚举对应。query和展示的时候在代码层转换，如果需要在SQL层面输出中文，用case when语句。

规范28：金额、数量等数值字段禁止设置成无符号unsigned或负数，按业务定义取值范围。

unsigned在某些场景下能让取值范围翻倍，但代价是所有相关计算都要注意无符号陷阱。MySQL中unsigned字段做减法的结果如果为负数，会报错或者变成很大的正数，非常诡异。更稳妥的写法是：明确数值字段的取值范围，用有符号类型，业务代码里控制非负逻辑。需要校验时，在应用层或触发器层面处理。

规范29：避免使用enum字段类型。

MySQL的enum类型看起来好用，写起来像在枚举型字符串，但它有几个隐藏问题：增加枚举值时需要alter table才能修改；排序、比较时按索引顺序而非字符串顺序，容易意外；不同MySQL版本对enum处理逻辑有差异。用tinyint代替enum，用代码维护枚举值，灵活度更高。

规范30：每个表尽量控制字段数量在30个以内，超过时考虑拆表。

一张表字段太多，比如六七十个字段，多半说明这张表承载了太多职责。典型的就是把商品基础信息、库存信息、价格信息、销售信息全塞进一张商品表，字段夸张到几十上百。这种表的问题：行数据太长，全表扫描IO高；分类查询时很多字段根本不需要，但select *会全部加载出来；后续扩展一个字段就要动大表，DDL耗时很长。正确的做法是把大表按业务域拆成多张表，用主键关联起来。如果真的无法避免字段过多，也要尽量把长文本字段拆出去，保证主表行短。

规范31：表与表关联使用逻辑外键，关联字段必须建立索引。

关联查询多表Join，如果关联字段没有索引，数据库就得做全表扫描，性能灾难。这一条的重要性被很多人低估，尤其新手，建了两张表，一个user_id放到订单表里就算完事了，查询2万行就得扫2万次，加个索引，瞬间变快。建议：所有业务表中的外键关联字段，一律建普通索引，保证Join和where筛选的效率。

*规范32：不要使用select ，但在建表阶段就应该尽量避免宽表设计。

这条好像跟建表规范无关，但实际上是建表时就埋下的隐患。select * 在大宽表上的性能问题，是表设计过宽导致的。规范30已经拆分了字段，这里再强调一次，字段按需加载，不要依赖select *。

规范33：表格设计完成后，必须补齐所有字段的comment注释。

注释是最便宜的文档。每张表用comment说明表的用途，每个字段用comment说明业务含义，包括枚举值含义，比如status字段的comment写成“状态：0-待支付，1-已支付，2-已取消”。这块工作看似多花几分钟，实际上为团队省了不少沟通成本。很多人接手老项目，最痛苦的就是看没有注释的字段，只能靠心电感应。

3.4 索引设计规范（第34条到第38条）

规范34：单表索引数量控制在5个以内，不要为所有可能的查询都建索引。

这个数字不是绝对的，是经验值。索引本身也要占用存储空间，每次插入、更新、删除都要同步维护索引，索引不是白送的，写入性能和存储成本都受它影响。很多新人建表时给十几个字段各建一个索引，结果一个写频繁的表写入性能骤降。正确的思路：先确定核心高频查询场景，为这些场景建索引；低频查询通过代码缓存解决，或者接受查库全表扫描。

规范35：联合索引考虑最左前缀原则，区分度高的字段放前面。

联合索引（a,b,c）相当于创建了(a)、(a,b)、(a,b,c)三个索引。设计联合索引时，一般把区分度高的字段放前面，因为MySQL会先按第一个字段筛选。比如订单表经常按user_id和status一起查，联合索引idx_user_id_status比分别建两个单列索引更高效。需要注意：查询条件里必须包含最左字段才能命中联合索引，否则索引失效。

规范36：加索引时优先加在where条件频繁使用的字段上，而不是select里出现的字段。

索引帮助的是查询定位，不是取数。select里出现的字段如果不在索引覆盖范围内，确实会导致回表，但前提是它最好出现在where或order by里。如果某个字段只出现在select中，对索引本身没有帮助，需要做覆盖索引优化的场景，可以再考虑把查询字段加到联合索引末尾。

规范37：唯一索引要和业务含义一致，不要仅仅为了能建唯一索引而建。

比如说用户表手机号，业务上不允许重复，就建uk_mobile。但有些重复可能来自软删除，比如用户注销了又重新注册，老记录还在表里deleted=1，新记录也带同一手机号，如果唯一索引建在deleted=0的手机号上，可能会冲突。所以唯一索引设计必须考虑业务逻辑，不能机械地认为某个字段唯一就建唯一索引，要考虑数据生命周期。

规范38：索引字段不要在函数或计算中使用，会导致索引失效。

在where子句中对索引列使用函数，比如where DATE(create_time)='2024-01-01'，MySQL无法直接利用create_time上的索引，只能全表扫描后执行函数计算。正确做法是改成范围查询：where create_time >= '2024-01-01' and create_time < '2024-01-02'。还有隐式转换同理，比如字段类型是varchar，查询时传了数字，MySQL会自动把字段转成数字再比较，索引也会失效。字段类型定义好之后，查询参数保持一致。

3.5 通用架构规范（第39条到第40条）

规范39：建表语句必须显式指定字符集和排序规则，不能依赖数据库默认值。

字符集选错是乱码的原罪。近几年最稳妥的方案是utf8mb4，它能存储emoji、生僻字，兼容性最好。排序规则使用utf8mb4_general_ci或utf8mb4_unicode_ci都可以，前者快，后者更准确，建议按数据库版本选。另外连接串里面也尽量指定characterEncoding=utf8，保证连接层的字符集一致，否则表字段和连接字符集不一致会导致乱码。

规范40：建表后必须补充表说明、维护人、改动历史，并同步更新数据库文档。

表设计规范最后一条是文档和流程。很多团队的数据库文档永远停留在上线那一天，后来改了字段，文档没有同步更新，做数据分析的同学摸瞎猜字段含义，最后都来找开发问。建议在数据库客户端里维护一个design doc，或者直接在注释里同步更新，每次表变更review时强制检查comment和文档是否同步。没有文档的表，就是一段无法读的代码。

4. 一个具体案例：从0到1设计用户订单表

光说规则有些抽象，我带你看一个完整例子。假设我们要为一个电商系统设计用户订单表和订单明细表，要求满足：有用户、有商品、有支付状态、支持逻辑删除、支持并发更新、需要审计追踪。

这是订单表结构示例：

sql复制CREATE TABLE odr_order (
  id BIGINT NOT NULL AUTO_INCREMENT COMMENT '主键ID',
  order_no VARCHAR(32) NOT NULL COMMENT '订单编号',
  user_id BIGINT NOT NULL COMMENT '用户ID',
  total_amount DECIMAL(10,2) NOT NULL DEFAULT 0.00 COMMENT '订单总金额（元）',
  status TINYINT NOT NULL DEFAULT 0 COMMENT '订单状态：0-待支付，1-已支付，2-已取消，3-已退款',
  address_snapshot VARCHAR(255) NOT NULL DEFAULT '' COMMENT '收货地址快照',
  remark VARCHAR(255) NOT NULL DEFAULT '' COMMENT '用户备注',
  version INT NOT NULL DEFAULT 0 COMMENT '乐观锁版本号',
  deleted TINYINT NOT NULL DEFAULT 0 COMMENT '逻辑删除：0-未删除，1-已删除',
  create_by BIGINT NOT NULL DEFAULT 0 COMMENT '创建人用户ID',
  update_by BIGINT NOT NULL DEFAULT 0 COMMENT '更新人用户ID',
  create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
  update_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间',
  PRIMARY KEY (id),
  UNIQUE KEY uk_order_no (order_no),
  KEY idx_user_id_status (user_id, status)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci COMMENT='订单主表';

这张表遵守了哪些规范？主键id是自增bigint，订单号有唯一索引，用户ID和状态做了联合索引，金额用decimal(10,2)，状态用tinyint数字编码，有逻辑删除字段，有version乐观锁，有创建人更新人，有crate_time、update_time，有comment注释，表名模块前缀odr_，表注释完整。

再看订单明细表：

sql复制CREATE TABLE odr_order_item (
  id BIGINT NOT NULL AUTO_INCREMENT COMMENT '主键ID',
  order_id BIGINT NOT NULL COMMENT '订单主表ID',
  product_id BIGINT NOT NULL COMMENT '商品ID',
  product_name VARCHAR(128) NOT NULL DEFAULT '' COMMENT '商品名称快照',
  product_price DECIMAL(10,2) NOT NULL DEFAULT 0.00 COMMENT '商品单价快照（元）',
  quantity INT NOT NULL DEFAULT 1 COMMENT '购买数量',
  subtotal DECIMAL(10,2) NOT NULL DEFAULT 0.00 COMMENT '小计金额（元）',
  create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
  update_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间',
  PRIMARY KEY (id),
  KEY idx_order_id (order_id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci COMMENT='订单明细表';

明细表通过order_id关联主表，order_id建了索引，商品名称和单价做快照存入，防止商品信息变更后订单历史数据变得不可追溯。两张表都没有使用物理外键，关联关系由代码层维护，查询时通过order_id走索引，性能完全够用。

5. 我实际执行这套规范时踩过的坑

规范定好了，执行起来才是真正见真章的地方。我在好几个团队推行这套规范，过程中遇到不少阻力，也总结出一些实际的执行心得。

第一个坑是成员习惯不一致。有人习惯用驼峰，有人爱用下划线，有人觉得字段长短无所谓，统一起来需要反复强调。后来我把命名规范做成一个Checkstyle插件，用代码扫描工具在MR阶段自动检查不合规的SQL脚本，不合规直接流水线失败，效率比开会强调高太多。

第二个坑是“为了规范而规范”，把表设计搞得很复杂。比如逻辑删除字段，不是所有表都需要，有些记录即使删了也没有业务价值，比如日志表、临时表，直接物理删除更合适。这套规范不是让你每张表都套满全部40条，而是按业务场景灵活把握。比如临时表、日志表、统计用中间表，可以适当简化。另外，并不是所有表都需要乐观锁version字段，导致并发更新问题的表才需要。

第三个坑是索引和字段类型选得过于保守或过于激进。太保守，刚上线就出现慢查询；太激进，建了一堆索引，写入性能下滑。我的建议是先用规范里的默认方案，比如所有外键字段建索引、核心表加version，上线后根据慢查询日志持续优化。

第四个坑是文档和工作流脱节。每次改表结构都要同步更新设计文档，这是最难执行的。到最后我发现，最好的文档就是表注释本身，把说明写全，让数据库结构自解释，文档只是辅助。所以每张表和字段的comment一定要写完整，尤其是枚举值和业务含义，这点再怎么强调都不过分。

第五个坑是主键生成策略。有些系统在业务早期选了UUID，后期数据量上来，想改成雪花ID，迁移成本非常高。所以前期没得选就用自增，后期有分布式需求了再用分布式ID，但尽量从一开始就确定好。

6. 常见问题与排查技巧实录

这套规范落地过程中，我收集了一些团队常问的问题和实际排查的经验，整理成速查表供参考。

还有一些常见问题，比如datetime和timestamp的选择。两者最大差别：timestamp存储的是UTC时间，范围到2038年；datetime不随时区变化，范围大得多。如果你的业务涉及海外用户，建议统一用datetime加业务时区处理，避免timestamp的2038问题。

再比如联合索引字段顺序问题。判断方式很简单：查询条件里哪种组合是最高频的，把区分度高的字段放前面。但也不是绝对，有时区分度一般但使用频率极高的字段也可以放在前面。真正靠谱的做法是拿真实数据量跑explain，对比possible_keys和key_len，看哪个索引实际生效、扫描行数更少。

7. 这套规范可以怎么延伸

如果你所在团队用MyBatis，可以结合通用Mapper或者MyBatis-Plus的自动填充功能，把create_time、update_time、create_by、update_by、deleted这些公共字段做成通用字段基类，代码生成器生成实体时自动带上，极大减少每个表单独写的重复代码。配合逻辑删除插件，自动在查询时加deleted=0条件，效果最好。

如果业务逐步走向微服务，数据库拆分是必然的事，那么表设计规范就更加重要了。拆表后，原来的一张订单表可能拆成订单基础服务、订单状态服务、订单明细服务等多个库，表前缀和命名规范能不能统一，直接决定了跨库查询时定位成本高不高。此时，你甚至可以给每个服务单独建一个库，库名前缀跟着服务模块名走，比如odr库、usr库、prd库，规则与表前缀一致。

如果公司开始做数据仓库或数据平台，这套规范也是基础。数据从业务库同步到数仓，元数据管理工具靠的就是表注释和字段注释，如果源头注释不全，数仓里基本就是一堆天书。

最后建议你把这40条规范复制下来，放在团队Wiki里，每次评审表结构时对着检查。不用一次到位，可以从命名+主键+核心字段这三块先推，等大家习惯了再往细节扩。我自己的体会是：规范的执行度比规范本身更重要，设计规范不是约束开发自由，而是把预期管理做到位，让每个后来人都能轻松接手。先让团队尝到甜头，后面推进就顺了。