简介：《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`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci COMMENT='订单主表';注意几个关键点：BIGINT UNSIGNED避免主键到达上限；VARCHAR(64)是订单号的保守长度，过长会拖累索引性能；status字段用TINYINT而不是字符串，理由是存储体积和比较效率；DEFAULT CURRENT_TIMESTAMP ON UPDATE让更新时间的维护交给数据库而不是应用层。
2.2 整数类型与金额、状态、布尔的三类选型对照
类型选型上，我见过最多的误用是两类：用VARCHAR存一切导致索引和排序失效；用DECIMAL存所有数值导致计算开销增大。这里给出一个可以直接抄走的对照表：
| 语义 | 推荐类型 | 禁止类型 | 说明 |
|---|---|---|---|
| 主键/外键 | BIGINT UNSIGNED | INT，VARCHAR | 单表记录数超 21 亿才用 BIGINT，但提前用无副作用 |
| 业务编号 | VARCHAR(32~64) | BIGINT | 业务编号需要保留前导零、字符含义 |
| 金额 | DECIMAL(12,2)或DECIMAL(14,4) | FLOAT/DOUBLE | 浮点二进制无法精确表示二进制小数 |
| 状态标记 | TINYINT | VARCHAR | 用注释维护状态枚举，前端映射单独做 |
| 布尔量 | TINYINT(1) | BIT | 配合 ORM 映射简单，避免 BIT 运算 |
| 时间 | DATETIME | TIMESTAMP，VARCHAR | TIMESTAMP 上限 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分析，重点看四列：
type：ALL是全表扫描，必须消灭；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)) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='订单主表';这段 DDL 的关键点是CONSTRAINT chk_order_status声明了约束名称。后续如果需要变更状态枚举，用ALTER TABLE ord_order DROP CHECK chk_order_status再新增即可；不命名的话，MySQL 会自动生成约束名，排查时很难对应到业务含义。
CHECK 约束不是 REST API 入参校验的替代，而是最后一道防线。应用层可以输入status=99写入失败时返回友好提示，但数据库层直接拒掉数据，可以防止绕过应用工具写入脏数据。对于状态流转的合法性（比如已取消不能变已支付），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中同一业务前缀分表的字段名集合，查出哪些分表字段不一致——这通常发生在某个分表被人手动加过字段而其他分表没同步时。
本文还有配套的精品资源，点击获取
