1. 写在前面的一个烂摊子没有规范的命名有多痛先讲段真实经历吧不是我编的是我在一个老项目里踩过的坑。那个项目的数据库几百张表命名风格堪称自由艺术展有全小写下划线命名的有驼峰命名的还有直接把中文拼音缩写堆上去的。业务表一会儿叫order一会儿叫tb_order一会儿又蹦出来一个orders。字段更离谱布尔类型一个叫is_deleted、一个叫deleted_flag、还有一个叫isDelete。最要命的是时间字段有的表叫createtime有的叫created_at有的叫gmt_create你查数据的时候根本分不清到底该信哪个。那时候我刚接手要写一个跨模块的报表查询光是把各表字段对齐就花了整整两天。你说这是技术难度大吗完全不是纯粹是命名混乱带来的沟通成本。从那以后我意识到数据库命名规范这种东西看着不起眼平时也没人表扬你规范做得好但一旦项目进入维护期、多团队协作、或者需要做数据分析它就成了决定你效率还是返工的分水岭。哪怕你就一个个人项目自己玩玩规范的命名也能让你三个月后再打开代码时不用对着自己曾经的杰作发呆。所以这篇文章我不打算讲什么高深理论也不会拿一套业界最终标准来压你因为所谓规范本质上是团队共识不同项目、不同规模有不同适配方案。我写这篇的定位是从一个在一线写过大量业务系统的人的角度给你一套可以直接拿去用的命名框架以及每个规则背后的为什么——你只有理解了为什么才不至于在遇到特殊情况时无所适从。如果你是个正在背规范文档的实习生或者是个准备定团队规矩的技术负责人这篇文章应该都值得你花几分钟看完。2. 先从库名说起你连数据库的名字都起不好后面全是坑2.1 库名到底在表达什么数据库名字是整个数据系统最顶层的标识它承担的责任是——让人在一堆服务、一堆项目中间一眼就能看出这个库是干嘛的。很多人不重视库名觉得反正连库的时候用的是配置名字丑点无所谓。这个想法大错特错。你想想当公司有几十个数据库实例、上百个库的时候你靠什么快速定位靠的就库名。库名要是乱七八糟整个团队每天的排查效率都在被它拖累。我自己比较推荐的库名结构是三层环境业务域用途。比如一个电商项目的订单库开发环境可以叫dev_order测试环境叫test_order生产环境叫prod_order或者像很多团队那样用order_db、order_service_db这种风格核心是有业务域和用途标识。业务域选什么词也有讲究最好用这个区域最稳定的业务名词而且尽量和微服务名、应用名保持对齐。比如你有个服务叫order-service那它的库最好就叫order这样一来人肉排查链路的时候从服务名到库名就不用再做一次翻译。2.2 库名的几个常见坏习惯我看过太多反面的例子这里列几个典型坏习惯你对照一下自己有没有用拼音缩写比如ddxt_db谁能看出来这是订单系统过两个月你自己都得猜。带编号db_01、db_02毫无语义纯粹给自己找麻烦。中文直接进库名有些开发工具确实支持但到了跨平台、跨工具的运维脚本里就是一颗随时会炸的雷。混用大小写MySQL在Linux下对库名大小写是敏感的你建个OrderDB换台服务器变成orderdb等着连接失败吧。这里有个特别容易踩的坑说一下库名一旦确定后面改起来极其痛苦。它不像代码里的变量重命名IDE帮你全局替换就行。库名会散落在配置文件、启动参数、运维脚本、监控系统、备份策略的各个角落你要改一个库名基本等于做一次小的迁移上线。所以在创建库之前一定要想清楚命名规则这个前置成本非常低后置成本高得惊人。2.3 环境怎么区分一个库还是多个库不少小团队喜欢搞一个库走天下生产、开发、测试全用一个库靠字段区分数据。这种作法短期省事长期是灾难——你的测试数据会污染生产统计你跑个批量脚本可能就把用户的真实数据给改了。我的建议是最起码在物理层面把环境拆开命名上直接体现。最简单的方案是加前缀dev_、test_、prod_。如果公司有更细的环境划分比如sit、uat、pre同理。这个前缀放在最前面方便按环境聚类筛选。有些团队喜欢后缀的写法比如order_dev、order_prod说实话也说得过去但只要团队统一就行最怕的就是有人用前缀有人用后缀导致排序、匹配脚本写起来两头不靠。2.4 再说说库名最大允许的长度不同数据库对名字长度有硬限制MySQL是64个字符PostgreSQL是63个字节注意是字节多字节字符要小心。Oracle的历史限制更苛刻以前是30个字符现在放宽到128了。虽然这些数字看着离我们很远——正常人不会把库名起几十个字符——但这里有一个容易被忽略的点你不仅在命名数据库还要考虑工具链的截断行为。有的监控系统收录库名时做了截断导致两个不同的库被合并成一条监控数据有的备份脚本模板把库名拼进文件名超长后间接把文件路径撑爆。这不是命名问题是生态问题。所以一个库名我个人的经验是最别超过20个字符干净利落在所有工具里都游刃有余。3. 表命名单复数之争其实不重要重要的是一致性和模块边界3.1 单数还是复数先把这个吵了八百年的问题定下来表名的单复数之争可以说是数据库命名圈子里最无聊、但又最容易引发团队内耗的话题之一。正方说order直观因为表里装的是订单这个概念反方说orders更准确因为你存的是多张订单也有人折中说用order_list。我来说点实在的。单数和复数本质上都没错因为SQL里你写select * from order也取决于具体数据库是否把它当保留字处理。单数名更接近实体建模中的实体名复数名更贴近容器的直觉这两者都能自圆其说。问题从来不出在单复数本身而出在团队里单数复数混着用。我就遇到过一张业务链路里order有可能是单数表order_items是复数表而orders又是另一张历史表三张表维度不同光对齐表名就够你喝一壶。所以我的建议是在立项第一天就把单数写进规范文档强制统一。我个人偏好单数原因是第一很多知名框架的默认ORM策略都是单数映射比如一些Java的JPA习惯单数表名和实体类名对齐更省事第二中文思维下我们本身没有单复数概念额外记一个复数规则属于无谓的认知负担。但请注意这只是我的偏好你用复数也完全没问题关键是定下来就不许改。3.2 表名要不要带前缀业务模块名必须是刚需表名最需要做的一件事是体现模块归属。你看很多做微服务的团队数据库的schema还是按老单体风格一张表裸奔表名只有user、order然后所有模块的表全部堆一起时间一长连这个表属于哪个域都搞不清了。以后做数据权限隔离、分库分表、甚至做数据地图的时候你都得靠猜。建议的格式是{模块名}_{业务表名}。比如用户模块的表user_account、user_address、user_login_log。订单模块的表order_main、order_item、order_pay_log。这样至少有三个好处一眼看出表属于哪个业务边界排查问题时的定位速度快很多避免不同模块之间同名表的冲突比如物流模块也有个package商品模块也有个package加上前缀就互不干扰后续做分库或者数据归档时用前缀做一个模糊匹配就能圈出整个模块的表清单。有同学会问那要不要把环境也写进表名比如prod_user_order。我的答案是千万别。环境信息属于库名的职责不该和表名混在一起。你想想同一套建表脚本要在dev、test、prod三个库执行表名如果带了环境那你就得准备三份脚本而且每次做对比时表名全都对不上纯属自虐。3.3 常见业务表分类与命名套路在实际业务系统里表大致可以分成几类每一类的命名套路稍微有些差异我在下面整理了一个表格表类型命名风格示例核心业务实体表{模块}_ 业务名词单数user_account、order_main关联关系表多对多{模块}_{主体}_{关联对象}_rel或直接用两个实体组合user_role_rel、order_product_rel配置类表{模块}_config或{模块}_settingsystem_config、pay_channel_config日志/流水表{模块}_{业务}_log或_record、_historyorder_pay_log、login_log字典/枚举表{模块}_dict或{模块}_enumsystem_dict、order_status_dict临时/中间表推荐加tmp_前缀且生命周期内尽快删除tmp_import_data_20250101注意我特别强调临时表——很多团队在跑数据修复时随手建一张tmp1、tmp2跑完也不删过半年数据库里躺着一堆僵尸表谁也不敢删。我建议临时表统一用tmp_前缀并且带上日期后缀比如tmp_order_fix_20250110这样从名字上你就能看出它的来龙去脉而且养成值用完就删的肌肉记忆。3.4 表名长度与缩写策略别搞语义截断表名的可读性比短更重要。一个名字order_payment_strategy_configuration虽然长但意思是清晰的比缩写opsc不知道强多少倍。缩写这个习惯必须戒掉因为缩写是团队内部的黑话你今天缩写一个cfg明天同事可能理解成conf后天新人直接懵圈。就算是同一个团队缩写词也经常产生二义性。所以表名宁可长一点也要保证无歧义完整表达。如果觉得太长影响使用了那说明你的模块粒度划分有问题而不是名字的问题——考虑拆表或者重新设计领域模型才是正解。4. 字段命名的骨灰级细节这才是整个规范里最见功力的地方4.1 字段命名第一原则全小写 下划线字段命名领域的最大公约数我认为是全小写 下划线分隔snake_case。为什么不是驼峰因为数据库的字段最终会出现在SQL脚本、导出数据、报表工具、数据仓库等多个环节中下划线风格在这些场景里容错性最高。你可以想想userName在Linux的shell脚本里、在Python的dict key里、在Excel的表头里都可能因为大小写风格不一致导致各种小麻烦而user_name几乎在所有地方都是安全的。同时大小写不敏感的数据环境下驼峰会让你被迫记哪个字母大写了这是完全没有必要的记忆负担。有个衍生问题值得注意字段要不要加表名前缀比如user表里是写id还是写user_id我的意见是如果字段在当前表内语义足够明确就不需要冗余前缀。在user表里id就是用户ID这没有歧义但如果你要写多表JOIN的SQL你会发现id字段在结果集里会互相覆盖所以我更推荐每个表都加一个带表名语义的逻辑主键别名方案——比如user表主键叫id但你在关联查询时显式地用u.id AS user_id。这个属于SQL书写习惯不是命名规范的范畴但两者配合起来很舒服。4.2 主键、外键、唯一键从字段名看关系在所有字段里最需要严格规范的是主键和外键。主键我建议统一用id类型统一bigint或者UUID千万别一会儿id一会儿user_id一会儿pk_id。对于外键字段命名原则是对端表名的单数形态 _id比如user表中的订单外键就是order_id订单表里的用户外键就是user_id。这样任何一个人拿起SQL看到order_id就知道它指向order表不需要查表结构文档。外键字段类型必须与主键完全一致不然索引都用不上这是血的教训——我之前遇到过一次慢查询排查了半天原因就是两个表关联字段一个是bigint一个是intJOIN时发生了隐式转换索引直接失效。唯一键的处理也值得提一嘴。比如你要给用户邮箱加唯一约束字段可能叫email但约束名我建议写成uk_user_email——用uk_前缀标注唯一约束unique key后面接表名和字段名。普通索引叫idx_user_email主键约束直接叫pk_表名。这个看起来只是约束命名的小事但它直接决定了你以后改索引、看执行计划、做在线DDL时的效率。缺省约束名的话每个数据库自动生成的约束名是随机字符串出问题的时候你连哪个约束在报错都搞不清楚。4.3 时间字段别再把创建时间叫成三种名字了时间字段简直是重灾区。我见过的有create_time、created_time、create_at、created_at、gmt_create、ctime……这还只是创建时间一个字段。这里我给出一个硬核建议也是我团队执行了五年没出过问题的方案创建时间created_at过去式强调被创建的时刻更新时间updated_at同理删除时间deleted_at配合软删除标记使用为什么用at而不是time因为*_at在英文语境里更明确指向时间点而time有时候会被误解成时间段或者时间跨度。当然很多人用create_time也用得很顺核心还是那句——只要统一就行。但既然定了规则我建议所有新增表都照上面这套走存量表可以渐进式改造。关于时间类型顺手多说一句强烈推荐统一用datetime或者timestamp——各有利弊datetime范围更大、不受时区影响timestamp占用空间更小但有时区转换的坑。团队选哪个我觉得都行但不要在同一套系统里混用。混用的后果是什么数据同步到数仓、做时间比较、按天分区分表的时候时区差八小时之类的诡异问题能让你查半个月。4.4 布尔字段、状态字段与枚举字段语义要自解释布尔字段的命名我认为is_前缀是好用的比如is_deleted、is_active、is_enabled。但要小心一点布尔值只表示两种状态的字段而现实世界中很多状态其实是三态甚至多态。比如订单状态你如果建三个布尔字段is_paid、is_shipped、is_finished那你就把自己逼进了墙角——组合状态一多判断就是一团乱麻。正确做法是设计一个status字段用枚举值表示配合一套状态机逻辑。状态字段的具体取值怎么定我建议用小写英文或数字枚举不推荐中文。中文取值在程序里到处写字符串字面量一不留神编码出问题就GG数字枚举省空间但可读性差需要靠注释维护小写英文是折中最优解pending、paid、shipped、cancelled。如果你非得用数字一定要确保在数据字典里登记得清清楚楚否则三年后没人知道4到底代表已取消还是已退款。4.5 命名长度、保留字与大小写敏感三个容易被忽略的雷字段名虽然不像库名那么受长度限制但每个数据库也有硬上限。MySQL字段名最长64字符这个一般不构成瓶颈真正麻烦的是保留字。很多业务字段名一不留神就撞上保留字比如order、group、desc、usage。虽然你可以写SQL时用反引号或者双引号包起来但这是给自己和工具链找麻烦——每次写代码都得多留个心眼。规避方法很简单建立一张保留字黑名单或者干脆形成习惯字段命名尽量带上业务限定词比如用order_no而不是order用group_code而不是group。还有一个大家容易忽略的点在大小写不敏感的数据库里你依然不应该在命名中依赖大小写来区分字段。比如MySQL字段在同一张表里不允许同时存在Name和name但很多人会犯混用风格的低级错误。统一小写下划线之后这个问题自然消失。5. 一套可以直接抄走的命名规范参考样例前面讲的都是原则这一节我直接给一套可落地的完整规范样例你可以直接复制到团队的Wiki里改吧改吧用。这套规范是我结合多个项目的实际经验沉淀出来的适用于绝大多数业务系统。5.1 完整规范速查表对象规范示例反例数据库名{环境}_{业务域}dev_order、prod_userddxt_db、DB01表名{模块}_{业务名}或{业务名}无歧义时可省略order_main、user_role_relOrderMain、order、tb1主键字段ididuser_id、pk_id外键字段{对端表单数}_idorder_idoid、orderid创建时间created_atcreated_atctime、create_time混乱更新时间updated_atupdated_atmodify_time、gmt_modified软删除标记is_deletedis_deleteddelFlag、deleted_flag混用状态字段statusstatusstate_flag、is_paid等布尔堆叠排序字段sort_nosort_noorder_index、sort混用备注/描述字段remarkremarkdesc保留字、comment混用常量/枚举名称大写加下划线PAY_STATUS_PAIDpayStatusPaid、支付成功布尔字段is_ 形容词/过去分词is_active、is_enabledvalid_flag、enable混合编号字段{业务}_noorder_noorder_number、order_num混用5.2 逐步创建一张规范表的示例以电商订单域为例从库到表再到字段完整走一遍流程你会有更直观的体感。库测试环境的订单库叫test_order。表订单主表叫order_main订单明细表叫order_item用户表叫user_account订单支付流水表叫order_pay_log。order_main的字段设计可以参考下面这个DDLCREATE TABLE order_main ( id bigint NOT NULL AUTO_INCREMENT COMMENT 主键, order_no varchar(32) NOT NULL COMMENT 订单编号, user_id bigint NOT NULL COMMENT 下单用户ID关联user_account.id, status varchar(20) NOT NULL DEFAULT pending COMMENT 订单状态: pending/paid/shipped/cancelled, total_amount decimal(12,2) NOT NULL DEFAULT 0.00 COMMENT 订单总金额(元), is_deleted tinyint(1) NOT NULL DEFAULT 0 COMMENT 软删除标记: 0-未删除, 1-已删除, created_at datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT 创建时间, updated_at 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 (user_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT订单主表;注意几个细节注释我要求每个字段必须写这不是给数据库看的是给三个月后的自己看的订单编号用uk_order_no唯一约束——业务上的唯一标识不应该靠业务逻辑单独保证必须落到数据库约束上金额类型用decimal而不是float/double因为浮点数做金额计算会有精度问题这个已经是软件工程的基本常识了但还是有人前赴后继地踩。5.3 字段注释数据库里最容易偷懒又最值得投入的地方关于注释我多说两句。很多人建表时不写COMMENT觉得代码里已经有注释了数据库注释可有可无。但你想过没有下游的数据分析同学、BI同学、数仓同学看数据时他们第一手接触到的就是数据库的表结构。如果字段没有注释他们就得来群里问这个字段是什么意思一次两次还好几十个字段全都没有注释的时候你每天光回答问题就能耗掉小半天。字段注释的写法也有讲究建议是语义 枚举值/取值范围说明。比如status字段注释订单状态: pending-待支付, paid-已支付, shipped-已发货, cancelled-已取消is_deleted字段注释软删除标记: 0-未删除, 1-已删除total_amount字段注释订单总金额单位元保留两位小数这样有限的信息量能把大多数疑惑扼杀在摇篮里。也有人问要不要在注释里写关联关系比如关联user_account.id我觉得可以写但要克制——只在关联字段上写不要每个字段都唠叨否则注释本身也变成噪音。6. 存量烂表的命名整改不改吧难受改吧伤筋动骨怎么破6.1 先评估要不要动存量命名坦白说只要项目在跑存量表的命名整改就不是一个能拍脑袋决定的事。改表名、改字段名的成本包括代码里所有SQL要同步、ORM映射要改、数据迁移脚本要写、下游同步任务要调、上线窗口要评估。如果你负责的是一个交易系统改一张核心表的字段名可能就得全链路回归测试。所以我的原则是增量表必须严守新规范存量表只对高频率接触面做改造其他能不动就不动。举个例子如果一张表只有你自己服务的三个SQL在用那改起来成本可控尽早改如果一张表被二十个服务引用其中有五个还在你找不到文档的老系统里那改造风险就非常大了。这时候建议靠别名视图来过渡比如建一个视图把旧字段映射成新字段名给下游提供一个新命名的替身等下游全部切换到视图以后再择机把物理表改掉。这个策略虽然不如一步到位那么彻底但它把风险拆小了对团队是负责任的。6.2 增量规范如何强制落地靠人不如靠工具规范写得再漂亮如果执行的时候全靠大家自觉那基本等于没写。人都是懒惰的业务压力大的时候什么规范都会抛到脑后。我在团队里落地规范有三个抓手第一是Code Review盯死。任何涉及DDL的改动评审时必须检查命名是否符合规范不符合就让人家改哪怕只是加一个日志表也不能放水。很多小错误就是从就这一次开始的松一次口子后面就堵不住了。第二是自动化巡检。写一个简单的SQL脚本定期从information_schema里捞表名和字段名用正则去匹配规范模式把不合规的列表发给团队。这个脚本本身不难写但威慑力巨大——没有谁愿意每周都被邮件批评命名不达标。第三是提供模板让人照抄。与其让每个开发在新建表时对着规范文档一个字一个字抠不如直接把常用表的DDL模板挂在Wiki上把主键、时间字段、软删除标记全都写死大家建表时复制粘贴改改业务字段就行。模板用起来了规范自然就成了习惯。6.3 数据字典让命名规范成为团队的公共知识最后强烈建议团队维护一份数据字典哪怕最初只是表格形式把一个模块的核心表、核心字段的语义、枚举值、更新频率、负责人统统记下来。数据字典本身不算新鲜事但很多团队的字典写着写着就荒废了原因通常是没人负责更新。我建议把它变成一个定期维护的活比如每逢新表上线就顺手更新每逢大版本上线就专项Review一次。数据字典的价值是累积的坚持半年之后分析需求、排查问题、做技术方案时你会发现自己翻字典的次数越来越多问人的次数越来越少。这就是规范化真正的回报——不是表面的整齐而是整个团队的信息传递效率上了一个台阶。7. 命名规范里那些看着对但实际是坑的细节补充7.1 大小写混排是规则里最大的漏洞很多人对全小写下划线有抵触觉得这个字段缩写一下更酷那个字段保持和接口命名一致更好。我理解这些想法但数据库字段是持久化层的命名它跟接口参数、Java属性是不一样的域。不要在数据库层追求跟代码保持一致因为代码里你能重构、编译器能帮你检查错误数据库里改一个字段名那可是牵一发动全身。所以一旦定了全小写下划线就不要允许任何人用驼峰出现在DDL里哪怕他觉得这个是私有表无所谓。规则没有例外例外是规则崩塌的开始。7.2 关于失败或错误信息的字段状态类字段里有个细节经常被忽略记录失败原因或者错误信息的字段。有人叫error_msg、有人叫fail_reason、有人叫err_desc、还有人叫ex_message。我建议统一为fail_reason或者error_msg二者择一。为什么强调这个因为绝大多数系统都有操作失败要记录原因的场景而很多人在设计表结构时根本想不起来预留这个字段都是上线后发现反馈不了失败原因紧急加列加的列名往往就是顺手一拍。不如把它列为规范里的一条每个核心操作流水表必须包含一个失败的描述字段然后把这个字段的命名提前定好。7.3 别再靠类型后缀来区分字段了有种老派的命名习惯喜欢在字段后面加类型后缀比如user_name_str、age_int、price_decimal。我强烈反对这种风格。类型信息是数据库schema本身就已经表达的你再写一遍纯属冗余而且如果哪天类型从varchar扩成text你还要把字段名里的_str摘掉吗字段名只承担业务语义这一件事类型的事情交给数据库自己管。7.4 软删除与唯一索引的一个隐藏矛盾使用is_deleted做软删除时有一个容易被坑的点如果你在user_account表上建了一个唯一索引uk_user_email那么用户删了之后这条记录的is_deleted变成1但email还在再插入同email的新用户会违反唯一约束。这个问题的解法业界有两种一是唯一索引里带上is_deleted二是删除时顺便把email改成一个带时间戳的占位值。我的建议是如果有软删除唯一约束的场景一定要在设计评审里就提出来千万不要等到上线后爆出唯一冲突再来补方案。这不是命名规范本身的问题却是命名规范实施中最常见的连锁反应。8. 最后说点实在话数据库命名规范这件事真的不是有洁癖的人才会做的事。它本质上是团队在用一个极低成本的方式给自己降低未来三到五年的沟通成本和维护成本。我见过太多项目前期赶进度命名随手写到了中期做数据分析、做跨系统对接的时候一次次为命名混乱买单付出的代价远超当初认真定规范和认真执行的那点时间。如果你问我从零启动一个项目时最值得花时间做的事是什么我一定会说花半天时间把团队命名规范写出来打印也好放到Wiki也好让每个人写第一张表之前就看到它。这半天时间的投资回报率高到超乎想象。最后送大家一个小工具思路——如果你用的是MySQL可以定期跑这样一段巡检SQL看看当前库里有多少表和字段是不符合你自己定的命名规范的SELECT table_name, column_name, data_type FROM information_schema.columns WHERE table_schema 你的库名 AND (column_name REGEXP [A-Z] OR column_name REGEXP [[:space:]] OR column_name LIKE %时间%) ORDER BY table_name;这段SQL会帮你找出驼峰字段、带空格的字段以及用中文命名的字段拿到清单之后按影响面从大到小排序逐个处理就行。规范这东西不怕晚就怕一直不开始。你现在在建的表就是三个月后别人要维护的表也是你自己三个月后要查询的表——对它好一点就是对自己好一点。
