2026/9/19 2:07:06
FEATURED · 精选文章 
简介《8数据库设计规范》是一份面向Oracle数据库设计与开发人员的规范化参考文档。文档系统梳理了数据库设计的核心策略包括对象长度规划、数据完整性实现强调遵循第二范式和第三范式减少外键和触发器、OLTP与OLAP的差异化设计以及字段类型的选型与长度约定同时给出数据库、表空间、表、字段、视图、索引等对象的命名规则并提供金额、税率、数量、名称等常用业务字段的类型定义建议帮助团队建立统一、稳定、高效的数据模型。资源为单个doc文档大小约296KB结构完整含变更记录、编写目的、策略说明、命名规范及数据模型产出物规范可直接用于企业内部设计规范制定或评审参考。已有267人学习使用适合数据库架构师、开发工程师及项目管理人员阅读。1. 规范文档的编号与演进为什么“第8篇”才是数据库的及格线文件名里的“8”大概率是贵司技术规范库里的第八篇文档也可能意味着这是第八次修订。放在公开语境里它暗示的是一件反直觉的事大多数团队不缺设计规范文档缺的是把规范嵌进日常开发动作里的执行机制。关系型数据库的建表语句、索引策略、命名习惯、类型选择单看任何一条都像常识但它们组合在一起会直接决定一次大促链路能不能撑住峰值、一个报表查询会不会拖垮主库、一次分库分表之后还能不能优雅归并。这篇文档的读者面很宽刚接手库表设计的新人需要一套“照着写就不会挨骂”的模板工作了五六年、正在做技术方案评审的人需要知道规范背后的取舍边界比如什么时候该打破范式、哪些索引是在给后续排障埋雷。所以下面的内容从表和字段的定义开始一直推进到约束、索引、分表策略与变更管理每一段都给可直接复用的参数和命令。目标只有一个按这套规范落地的项目经得起三年后别人的接手也经得起流量高峰的抽检。2. 表与字段设计规范命名、类型与元信息的三层约束2.1 表命名与字段命名的强制前缀体系常见的做法是用业务域缩写做表前缀而不是让表名裸奔。比如订单域统一以ord_开头用户域是usr_商品域是prd_。这样做的好处并不是视觉统一这么简单——你在写 SQL 的时候SELECT * FROM ord_order和SELECT * FROM order_info相比前者可以直接告诉你这个表属于哪个业务域权限体系也能按前缀批量配置做数据归档时按前缀正则匹配即可。字段命名的硬性规则我总结三条主键一律叫id类型看下面的说明不做业务含义携带。所有时间字段后缀统一_at所有状态字段后缀统一_status所有计数字段后缀统一_count。外键字段命名必须与引用表主键同名比如product_id引用prd_product.id禁止出现pid、goods_id这类二次映射。这看起来是洁癖但实际收益体现在 JOIN 和排障上。你维护一个半年没碰过的慢查询看到o.user_id u.id不需要去翻数据字典数据字典里出现一个u.uid排查时就必须猜。下面是一个满足规范的标准建表样例CREATE TABLE ord_order ( id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT COMMENT 主键, order_no VARCHAR(64) NOT NULL COMMENT 业务订单号, user_id BIGINT UNSIGNED NOT NULL COMMENT 下单用户ID, amount DECIMAL(12,2) NOT NULL DEFAULT 0.00 COMMENT 订单金额, status TINYINT NOT NULL DEFAULT 0 COMMENT 订单状态 0-待支付 1-已支付 2-已取消, paid_at DATETIME DEFAULT NULL COMMENT 支付时间, 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 COLLATEutf8mb4_0900_ai_ci COMMENT订单主表;注意几个关键点BIGINT UNSIGNED避免主键到达上限VARCHAR(64)是订单号的保守长度过长会拖累索引性能status字段用TINYINT而不是字符串理由是存储体积和比较效率DEFAULT CURRENT_TIMESTAMP ON UPDATE让更新时间的维护交给数据库而不是应用层。2.2 整数类型与金额、状态、布尔的三类选型对照类型选型上我见过最多的误用是两类用VARCHAR存一切导致索引和排序失效用DECIMAL存所有数值导致计算开销增大。这里给出一个可以直接抄走的对照表语义推荐类型禁止类型说明主键/外键BIGINT UNSIGNEDINTVARCHAR单表记录数超 21 亿才用 BIGINT但提前用无副作用业务编号VARCHAR(32~64)BIGINT业务编号需要保留前导零、字符含义金额DECIMAL(12,2)或DECIMAL(14,4)FLOAT/DOUBLE浮点二进制无法精确表示二进制小数状态标记TINYINTVARCHAR用注释维护状态枚举前端映射单独做布尔量TINYINT(1)BIT配合 ORM 映射简单避免 BIT 运算时间DATETIMETIMESTAMPVARCHARTIMESTAMP 上限 2038 年且有时区坑TIMESTAMP不是不能用而是到了 2038 年会溢出DATETIME的存储范围是 1000-01-01 到 9999-12-31对多数业务足够。如果系统面向全球用户需要记录时区正确做法是统一存 UTC 的DATETIME展示层再转本地时间。2.3 通用字段主键、created_at、update_at 的默认约定每张表必须包含四件套id、created_at、updated_at以及一个用于软删除如果业务需要的deleted_at。前两个是硬性最低配置后一个按业务场景选配。物理删除与软删除的选择如果表涉及用户资产、资金流水、审计日志一律软删除纯中间表、临时表可以物理删除。软删除的默认值用NULL表示未删除有值时存删除时间。这个设计和WHERE deleted_at IS NULL配合能正常走索引如果用0/1标记统计时多一个过滤条件且无法感知删除时间。updated_at的自动更新依赖ON UPDATE CURRENT_TIMESTAMP。这里有个容易踩的坑批量 UPDATE 语句即使没有实际修改任何字段值只要 WHERE 条件命中了记录updated_at也会被刷新。方案是应用层在更新时如果无字段变更跳过 UPDATE或者接受这种“脏刷新”前提是不要用updated_at做增量同步的依据改用 binlog。3. 索引设计规范从查询模式反推索引而不是从字段反推3.1 覆盖索引与回表之间的取舍原则索引设计规范的第一原则索引不是对字段加的是对查询模式加的。建表时不要把每个字段都扣一个索引而是先列出核心查询语句找出它们的WHERE、ORDER BY、GROUP BY字段再决定索引组合。覆盖索引的价值在于避免回表。比如高频查询是SELECT user_id, status FROM ord_order WHERE order_no ?那么建立(order_no, user_id, status)的联合索引查询结果全部在索引页中不需要访问聚簇索引。代价是索引存储空间增大、写入变慢。取舍标准是这个查询的 QPS 有多高如果它每秒执行数百次用空间换时间值得如果只是后台报表偶尔跑没必要覆盖。联合索引的最左前缀原则必须吃透。(user_id, status, created_at)这个索引能命中user_id单独查询、user_id status查询、user_id status created_at范围查询但直接查status或created_at是走不了索引的。我见过大量团队把联合索引反着建导致“明明建了索引EXPLAIN 还是全表扫描”。3.2 慢查询日志与EXPLAIN 的实际判定参数发现索引问题的标准流程不是猜是看慢查询日志和EXPLAIN。MySQL 开启慢日志的配置参数如下slow_query_log 1 slow_query_log_file /var/log/mysql/slow.log long_query_time 1 log_queries_not_using_indexes 1long_query_time 1表示超过 1 秒的 SQL 记录log_queries_not_using_indexes会记录所有没走索引的查询这在优化阶段会刷屏但能暴露隐藏的问题。生产环境建议只开第一和第三个避免第二个产生过多日志。拿到慢 SQL 后用EXPLAIN分析重点看四列typeALL是全表扫描必须消灭range/ref/eq_ref是合格的。key实际命中的索引名NULL表示没走索引。rows预估扫描行数和实际返回行数差距过大说明统计信息失真或索引失效。Extra出现Using filesort或Using temporary时SQL 排序或分组没有完全走索引通常需要调整联合索引字段顺序来消除。比如ORDER BY created_at DESC LIMIT 20这条语句如果索引是(user_id, status, created_at)则排序完全在索引内完成Extra不会出现Using filesort但如果条件里只带了user_id而排序里用了updated_at则必然出现文件排序。3.3 唯一索引与普通索引的场景边界唯一索引要省着用。它的每一次写入都要额外检查唯一性多一个索引就多一次查找。业务主键、业务单号、身份证号这类字段必须唯一但状态字段、类型字段不要加唯一索引——这不是业务约束反而在并发插入时形成热点锁等待。带业务含义的唯一索引命名统一为uk_前缀普通索引统一为idx_前缀。这样在SHOW INDEX FROM输出的列表里扫一眼名字就能判断这个索引是否可以删除。一次索引清理的常见操作是对比慢查询日志中的应用场景和现有索引把三个月内没被EXPLAIN命中的索引直接下线。4. 约束与外键从逻辑正确到物理完整性的边界4.1 外键为什么建议禁用以及替代方案关系型数据库规范里争议最大的点就是外键约束。我倾向于默认禁用 FOREIGN KEY尤其是在分库分表的架构下跨库外键本身就失去意义。但这不代表放弃数据完整性而是用应用层事务保证。替代方案是保留逻辑外键也就是只保留关联字段不加数据库级约束。在业务代码中通过事务包裹多表写入出现异常时整体回滚。对于必须保证强一致的场景比如订单与订单明细可以用数据库事务 唯一约束来保证对于弱一致的场景比如用户与订单历史用异步补偿机制处理。禁用外键的最实际理由是运维成本。DDL 变更时有外键的表需要先检查子表批量导入数据时要按依赖顺序做分库分表中间件对外键的支持普遍不好。如果团队规模小、表数量少且没有分库计划保留外键也不是罪过判断依据是是否有并发导入、是否需要平滑扩容。4.2 CHECK 约束与状态机的落地写法MySQL 8.0.16 之后 CHECK 约束真正生效。状态字段的合法性建议用 CHECK 约束兜底而不是完全信任应用层CREATE TABLE ord_order ( id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT COMMENT 主键, order_no VARCHAR(64) NOT NULL COMMENT 业务订单号, status TINYINT NOT NULL DEFAULT 0 COMMENT 订单状态, PRIMARY KEY (id), CONSTRAINT chk_order_status CHECK (status IN (0, 1, 2)) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT订单主表;这段 DDL 的关键点是CONSTRAINT chk_order_status声明了约束名称。后续如果需要变更状态枚举用ALTER TABLE ord_order DROP CHECK chk_order_status再新增即可不命名的话MySQL 会自动生成约束名排查时很难对应到业务含义。CHECK 约束不是 REST API 入参校验的替代而是最后一道防线。应用层可以输入status99写入失败时返回友好提示但数据库层直接拒掉数据可以防止绕过应用工具写入脏数据。对于状态流转的合法性比如已取消不能变已支付CHECK 表达式写不出这种状态机需要应用层做判断或者用存储过程不推荐。4.3 缺失约束导致的脏数据案例没有约束的典型事故场景订单表status字段接入了新的对接方对方文档写错直接把3已退款写成5数据库照单全收。三天后对账系统发现金额对不上回溯数据时才发现有一批订单状态是非法值。如果有CHECK约束这批量数据从一开始就写不进去。另一个典型是金额字段。没有CHECK (amount 0)的情况下某个促销工具的取反逻辑把正数改成负数成功入库导致商户余额负数。应用层加了校验仍然可能出现漏网之鱼因为每接入一个新系统别人不一定会遵守你的文档。数据库约束是唯一不受调用方影响的保证。5. 变更管理与自助校验让规范在协作中自动生效5.1 表结构变更的留存与回滚策略数据库规范文档写了不执行等于废纸。执行的关键不是让大家背规范而是把规范固化到流程里。常见的做法是建表语句、ALTER 语句统一收进 Git 仓库的migrations目录每个变更一个文件文件名按时间戳或序号编排代码评审时顺带评审 DDL。回滚策略分两类可逆变更与不可逆变更。加字段、加索引是可逆的回滚 DDL 直接删即可删字段、删表、修改字段类型是基本不可逆的变更前必须备份原表结构或者用pt-online-schema-change这类工具做在线变更避免锁表。在线变更工具核心逻辑是先拷贝数据到新表同步 binlog业务低峰期切换表名。使用它的前提是表必须有主键且原表不能有触发器。这三个条件在常规业务表上都能满足但大表的 COUNT 查询会被拷贝过程阻塞需要提前评估。5.2 自查规范覆盖度的三个实用 SQL 语句规范执行的最后一步是检查。每月跑一次以下三条 SQL能快速找出不符合规范的库对象。第一条找出所有没有主键的表SELECT t.TABLE_NAME FROM information_schema.TABLES t LEFT JOIN information_schema.TABLE_CONSTRAINTS tc ON tc.TABLE_SCHEMA t.TABLE_SCHEMA AND tc.TABLE_NAME t.TABLE_NAME AND tc.CONSTRAINT_TYPE PRIMARY KEY WHERE t.TABLE_SCHEMA your_db AND t.TABLE_TYPE BASE TABLE AND tc.CONSTRAINT_NAME IS NULL;第二条找出所有字符集不是utf8mb4的表SELECT TABLE_NAME, TABLE_COLLATION FROM information_schema.TABLES WHERE TABLE_SCHEMA your_db AND TABLE_COLLATION NOT LIKE utf8mb4%;第三条找出没有任何索引的表SELECT t.TABLE_NAME FROM information_schema.TABLES t LEFT JOIN information_schema.STATISTICS s ON s.TABLE_SCHEMA t.TABLE_SCHEMA AND s.TABLE_NAME t.TABLE_NAME WHERE t.TABLE_SCHEMA your_db AND t.TABLE_TYPE BASE TABLE AND s.INDEX_NAME IS NULL;这三条 SQL 输出结果后逐张表确认是业务如此设计还是遗漏。另一个常用技巧是查information_schema.STATISTICS中INDEX_NAME不以uk_或idx_开头的记录找出命名不规范的索引。5.3 用元数据核对分表字段是否漏加分库分表场景下最容易漏掉的是分表字段本身没有索引。比如按user_id分表但建表时只给主键加了索引业务查询WHERE user_id ?直接全表扫描。运行这条 SQL 核查SELECT TABLE_NAME, INDEX_NAME, COLUMN_NAME FROM information_schema.STATISTICS WHERE TABLE_SCHEMA your_db AND SEQ_IN_INDEX 1 AND COLUMN_NAME user_id;SEQ_IN_INDEX 1限定联合索引的第一列确保user_id在索引的最左位置而不是被埋在其他耦合字段后面。如果返回结果为空说明该表缺了最基础的分表查询索引。一个更彻底的检查是把所有表名以_00到_99结尾的分表做一遍前述三条检查确保镜像表之间的结构一致性。常见做法是定期对比information_schema.COLUMNS中同一业务前缀分表的字段名集合查出哪些分表字段不一致——这通常发生在某个分表被人手动加过字段而其他分表没同步时。本文还有配套的精品资源点击获取
MySQL数据库设计规范：表结构、索引与约束的工程实践
简介《8数据库设计规范》是一份面向Oracle数据库设计与开发人员的规范化参考文档。文档系统梳理了数据库设计的核心策略包括对象长度规划、数据完整性实现强调遵循第二范式和第三范式减少外键和触发器、OLTP与OLAP的差异化设计以及字段类型的选型与长度约定同时给出数据库、表空间、表、字段、视图、索引等对象的命名规则并提供金额、税率、数量、名称等常用业务字段的类型定义建议帮助团队建立统一、稳定、高效的数据模型。资源为单个doc文档大小约296KB结构完整含变更记录、编写目的、策略说明、命名规范及数据模型产出物规范可直接用于企业内部设计规范制定或评审参考。已有267人学习使用适合数据库架构师、开发工程师及项目管理人员阅读。1. 规范文档的编号与演进为什么“第8篇”才是数据库的及格线文件名里的“8”大概率是贵司技术规范库里的第八篇文档也可能意味着这是第八次修订。放在公开语境里它暗示的是一件反直觉的事大多数团队不缺设计规范文档缺的是把规范嵌进日常开发动作里的执行机制。关系型数据库的建表语句、索引策略、命名习惯、类型选择单看任何一条都像常识但它们组合在一起会直接决定一次大促链路能不能撑住峰值、一个报表查询会不会拖垮主库、一次分库分表之后还能不能优雅归并。这篇文档的读者面很宽刚接手库表设计的新人需要一套“照着写就不会挨骂”的模板工作了五六年、正在做技术方案评审的人需要知道规范背后的取舍边界比如什么时候该打破范式、哪些索引是在给后续排障埋雷。所以下面的内容从表和字段的定义开始一直推进到约束、索引、分表策略与变更管理每一段都给可直接复用的参数和命令。目标只有一个按这套规范落地的项目经得起三年后别人的接手也经得起流量高峰的抽检。2. 表与字段设计规范命名、类型与元信息的三层约束2.1 表命名与字段命名的强制前缀体系常见的做法是用业务域缩写做表前缀而不是让表名裸奔。比如订单域统一以ord_开头用户域是usr_商品域是prd_。这样做的好处并不是视觉统一这么简单——你在写 SQL 的时候SELECT * FROM ord_order和SELECT * FROM order_info相比前者可以直接告诉你这个表属于哪个业务域权限体系也能按前缀批量配置做数据归档时按前缀正则匹配即可。字段命名的硬性规则我总结三条主键一律叫id类型看下面的说明不做业务含义携带。所有时间字段后缀统一_at所有状态字段后缀统一_status所有计数字段后缀统一_count。外键字段命名必须与引用表主键同名比如product_id引用prd_product.id禁止出现pid、goods_id这类二次映射。这看起来是洁癖但实际收益体现在 JOIN 和排障上。你维护一个半年没碰过的慢查询看到o.user_id u.id不需要去翻数据字典数据字典里出现一个u.uid排查时就必须猜。下面是一个满足规范的标准建表样例CREATE TABLE ord_order ( id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT COMMENT 主键, order_no VARCHAR(64) NOT NULL COMMENT 业务订单号, user_id BIGINT UNSIGNED NOT NULL COMMENT 下单用户ID, amount DECIMAL(12,2) NOT NULL DEFAULT 0.00 COMMENT 订单金额, status TINYINT NOT NULL DEFAULT 0 COMMENT 订单状态 0-待支付 1-已支付 2-已取消, paid_at DATETIME DEFAULT NULL COMMENT 支付时间, 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 COLLATEutf8mb4_0900_ai_ci COMMENT订单主表;注意几个关键点BIGINT UNSIGNED避免主键到达上限VARCHAR(64)是订单号的保守长度过长会拖累索引性能status字段用TINYINT而不是字符串理由是存储体积和比较效率DEFAULT CURRENT_TIMESTAMP ON UPDATE让更新时间的维护交给数据库而不是应用层。2.2 整数类型与金额、状态、布尔的三类选型对照类型选型上我见过最多的误用是两类用VARCHAR存一切导致索引和排序失效用DECIMAL存所有数值导致计算开销增大。这里给出一个可以直接抄走的对照表语义推荐类型禁止类型说明主键/外键BIGINT UNSIGNEDINTVARCHAR单表记录数超 21 亿才用 BIGINT但提前用无副作用业务编号VARCHAR(32~64)BIGINT业务编号需要保留前导零、字符含义金额DECIMAL(12,2)或DECIMAL(14,4)FLOAT/DOUBLE浮点二进制无法精确表示二进制小数状态标记TINYINTVARCHAR用注释维护状态枚举前端映射单独做布尔量TINYINT(1)BIT配合 ORM 映射简单避免 BIT 运算时间DATETIMETIMESTAMPVARCHARTIMESTAMP 上限 2038 年且有时区坑TIMESTAMP不是不能用而是到了 2038 年会溢出DATETIME的存储范围是 1000-01-01 到 9999-12-31对多数业务足够。如果系统面向全球用户需要记录时区正确做法是统一存 UTC 的DATETIME展示层再转本地时间。2.3 通用字段主键、created_at、update_at 的默认约定每张表必须包含四件套id、created_at、updated_at以及一个用于软删除如果业务需要的deleted_at。前两个是硬性最低配置后一个按业务场景选配。物理删除与软删除的选择如果表涉及用户资产、资金流水、审计日志一律软删除纯中间表、临时表可以物理删除。软删除的默认值用NULL表示未删除有值时存删除时间。这个设计和WHERE deleted_at IS NULL配合能正常走索引如果用0/1标记统计时多一个过滤条件且无法感知删除时间。updated_at的自动更新依赖ON UPDATE CURRENT_TIMESTAMP。这里有个容易踩的坑批量 UPDATE 语句即使没有实际修改任何字段值只要 WHERE 条件命中了记录updated_at也会被刷新。方案是应用层在更新时如果无字段变更跳过 UPDATE或者接受这种“脏刷新”前提是不要用updated_at做增量同步的依据改用 binlog。3. 索引设计规范从查询模式反推索引而不是从字段反推3.1 覆盖索引与回表之间的取舍原则索引设计规范的第一原则索引不是对字段加的是对查询模式加的。建表时不要把每个字段都扣一个索引而是先列出核心查询语句找出它们的WHERE、ORDER BY、GROUP BY字段再决定索引组合。覆盖索引的价值在于避免回表。比如高频查询是SELECT user_id, status FROM ord_order WHERE order_no ?那么建立(order_no, user_id, status)的联合索引查询结果全部在索引页中不需要访问聚簇索引。代价是索引存储空间增大、写入变慢。取舍标准是这个查询的 QPS 有多高如果它每秒执行数百次用空间换时间值得如果只是后台报表偶尔跑没必要覆盖。联合索引的最左前缀原则必须吃透。(user_id, status, created_at)这个索引能命中user_id单独查询、user_id status查询、user_id status created_at范围查询但直接查status或created_at是走不了索引的。我见过大量团队把联合索引反着建导致“明明建了索引EXPLAIN 还是全表扫描”。3.2 慢查询日志与EXPLAIN 的实际判定参数发现索引问题的标准流程不是猜是看慢查询日志和EXPLAIN。MySQL 开启慢日志的配置参数如下slow_query_log 1 slow_query_log_file /var/log/mysql/slow.log long_query_time 1 log_queries_not_using_indexes 1long_query_time 1表示超过 1 秒的 SQL 记录log_queries_not_using_indexes会记录所有没走索引的查询这在优化阶段会刷屏但能暴露隐藏的问题。生产环境建议只开第一和第三个避免第二个产生过多日志。拿到慢 SQL 后用EXPLAIN分析重点看四列typeALL是全表扫描必须消灭range/ref/eq_ref是合格的。key实际命中的索引名NULL表示没走索引。rows预估扫描行数和实际返回行数差距过大说明统计信息失真或索引失效。Extra出现Using filesort或Using temporary时SQL 排序或分组没有完全走索引通常需要调整联合索引字段顺序来消除。比如ORDER BY created_at DESC LIMIT 20这条语句如果索引是(user_id, status, created_at)则排序完全在索引内完成Extra不会出现Using filesort但如果条件里只带了user_id而排序里用了updated_at则必然出现文件排序。3.3 唯一索引与普通索引的场景边界唯一索引要省着用。它的每一次写入都要额外检查唯一性多一个索引就多一次查找。业务主键、业务单号、身份证号这类字段必须唯一但状态字段、类型字段不要加唯一索引——这不是业务约束反而在并发插入时形成热点锁等待。带业务含义的唯一索引命名统一为uk_前缀普通索引统一为idx_前缀。这样在SHOW INDEX FROM输出的列表里扫一眼名字就能判断这个索引是否可以删除。一次索引清理的常见操作是对比慢查询日志中的应用场景和现有索引把三个月内没被EXPLAIN命中的索引直接下线。4. 约束与外键从逻辑正确到物理完整性的边界4.1 外键为什么建议禁用以及替代方案关系型数据库规范里争议最大的点就是外键约束。我倾向于默认禁用 FOREIGN KEY尤其是在分库分表的架构下跨库外键本身就失去意义。但这不代表放弃数据完整性而是用应用层事务保证。替代方案是保留逻辑外键也就是只保留关联字段不加数据库级约束。在业务代码中通过事务包裹多表写入出现异常时整体回滚。对于必须保证强一致的场景比如订单与订单明细可以用数据库事务 唯一约束来保证对于弱一致的场景比如用户与订单历史用异步补偿机制处理。禁用外键的最实际理由是运维成本。DDL 变更时有外键的表需要先检查子表批量导入数据时要按依赖顺序做分库分表中间件对外键的支持普遍不好。如果团队规模小、表数量少且没有分库计划保留外键也不是罪过判断依据是是否有并发导入、是否需要平滑扩容。4.2 CHECK 约束与状态机的落地写法MySQL 8.0.16 之后 CHECK 约束真正生效。状态字段的合法性建议用 CHECK 约束兜底而不是完全信任应用层CREATE TABLE ord_order ( id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT COMMENT 主键, order_no VARCHAR(64) NOT NULL COMMENT 业务订单号, status TINYINT NOT NULL DEFAULT 0 COMMENT 订单状态, PRIMARY KEY (id), CONSTRAINT chk_order_status CHECK (status IN (0, 1, 2)) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT订单主表;这段 DDL 的关键点是CONSTRAINT chk_order_status声明了约束名称。后续如果需要变更状态枚举用ALTER TABLE ord_order DROP CHECK chk_order_status再新增即可不命名的话MySQL 会自动生成约束名排查时很难对应到业务含义。CHECK 约束不是 REST API 入参校验的替代而是最后一道防线。应用层可以输入status99写入失败时返回友好提示但数据库层直接拒掉数据可以防止绕过应用工具写入脏数据。对于状态流转的合法性比如已取消不能变已支付CHECK 表达式写不出这种状态机需要应用层做判断或者用存储过程不推荐。4.3 缺失约束导致的脏数据案例没有约束的典型事故场景订单表status字段接入了新的对接方对方文档写错直接把3已退款写成5数据库照单全收。三天后对账系统发现金额对不上回溯数据时才发现有一批订单状态是非法值。如果有CHECK约束这批量数据从一开始就写不进去。另一个典型是金额字段。没有CHECK (amount 0)的情况下某个促销工具的取反逻辑把正数改成负数成功入库导致商户余额负数。应用层加了校验仍然可能出现漏网之鱼因为每接入一个新系统别人不一定会遵守你的文档。数据库约束是唯一不受调用方影响的保证。5. 变更管理与自助校验让规范在协作中自动生效5.1 表结构变更的留存与回滚策略数据库规范文档写了不执行等于废纸。执行的关键不是让大家背规范而是把规范固化到流程里。常见的做法是建表语句、ALTER 语句统一收进 Git 仓库的migrations目录每个变更一个文件文件名按时间戳或序号编排代码评审时顺带评审 DDL。回滚策略分两类可逆变更与不可逆变更。加字段、加索引是可逆的回滚 DDL 直接删即可删字段、删表、修改字段类型是基本不可逆的变更前必须备份原表结构或者用pt-online-schema-change这类工具做在线变更避免锁表。在线变更工具核心逻辑是先拷贝数据到新表同步 binlog业务低峰期切换表名。使用它的前提是表必须有主键且原表不能有触发器。这三个条件在常规业务表上都能满足但大表的 COUNT 查询会被拷贝过程阻塞需要提前评估。5.2 自查规范覆盖度的三个实用 SQL 语句规范执行的最后一步是检查。每月跑一次以下三条 SQL能快速找出不符合规范的库对象。第一条找出所有没有主键的表SELECT t.TABLE_NAME FROM information_schema.TABLES t LEFT JOIN information_schema.TABLE_CONSTRAINTS tc ON tc.TABLE_SCHEMA t.TABLE_SCHEMA AND tc.TABLE_NAME t.TABLE_NAME AND tc.CONSTRAINT_TYPE PRIMARY KEY WHERE t.TABLE_SCHEMA your_db AND t.TABLE_TYPE BASE TABLE AND tc.CONSTRAINT_NAME IS NULL;第二条找出所有字符集不是utf8mb4的表SELECT TABLE_NAME, TABLE_COLLATION FROM information_schema.TABLES WHERE TABLE_SCHEMA your_db AND TABLE_COLLATION NOT LIKE utf8mb4%;第三条找出没有任何索引的表SELECT t.TABLE_NAME FROM information_schema.TABLES t LEFT JOIN information_schema.STATISTICS s ON s.TABLE_SCHEMA t.TABLE_SCHEMA AND s.TABLE_NAME t.TABLE_NAME WHERE t.TABLE_SCHEMA your_db AND t.TABLE_TYPE BASE TABLE AND s.INDEX_NAME IS NULL;这三条 SQL 输出结果后逐张表确认是业务如此设计还是遗漏。另一个常用技巧是查information_schema.STATISTICS中INDEX_NAME不以uk_或idx_开头的记录找出命名不规范的索引。5.3 用元数据核对分表字段是否漏加分库分表场景下最容易漏掉的是分表字段本身没有索引。比如按user_id分表但建表时只给主键加了索引业务查询WHERE user_id ?直接全表扫描。运行这条 SQL 核查SELECT TABLE_NAME, INDEX_NAME, COLUMN_NAME FROM information_schema.STATISTICS WHERE TABLE_SCHEMA your_db AND SEQ_IN_INDEX 1 AND COLUMN_NAME user_id;SEQ_IN_INDEX 1限定联合索引的第一列确保user_id在索引的最左位置而不是被埋在其他耦合字段后面。如果返回结果为空说明该表缺了最基础的分表查询索引。一个更彻底的检查是把所有表名以_00到_99结尾的分表做一遍前述三条检查确保镜像表之间的结构一致性。常见做法是定期对比information_schema.COLUMNS中同一业务前缀分表的字段名集合查出哪些分表字段不一致——这通常发生在某个分表被人手动加过字段而其他分表没同步时。本文还有配套的精品资源点击获取 
