企业官网建设流程全解析

1. 为什么要有一份“能抄作业”的 MySQL 设计规范：先讲一次线上事故

我到现在都还记得那次事故。凌晨两点，监控群突然炸了，告警刷了一屏：订单表全表扫描，数据库 CPU 直接顶到百分之百，所有写请求开始排队。等我登录上去一看，问题出在一个很不起眼的地方：新同事在查询条件里用了一张表的 varchar 字段，而那字段连索引都没有，表数据量已经破了千万。更无奈的是，这张表设计的时候字段名叫user_name，另一张关联表叫username，业务代码里 Join 时写错了一个，没人发现，因为这个字段从一开始就没按统一规范设计。

这类事故不是偶然的。数据库设计规范看起来像是一堆琐碎的规定，实际上它是把团队里每个人的经验、教训沉淀成一套共同语言。它解决的问题不是某一个 SQL 写得不好，而是：所有人的建表方式、命名方式、字段类型、索引策略都保持一致，让系统在数据量上来之后依然可预期、可维护、可排查。

如果你是一个两三人的小项目，规范看起来是多余的。可一旦表数量超过五十张，参与开发的超过三个人，没有规范的数据库就是一座随时会塌的积木塔。你会看到这些真实场景：

• 同一个含义的字段，有人叫created_at，有人叫create_time，还有人叫gmt_create，联表查询全靠猜。
• 有的表用自增主键，有的用 UUID，有的干脆没有主键。
• 金额字段有人用decimal，有人用float，算到最后对不上账。
• 时间字段一半是datetime，一半是int存时间戳，排序、格式化全靠脑子换算。

这些不是纯技术问题，是管理问题。规范的真正价值，是让数据库在变成事故之前，就先规避掉大概率会踩的坑。所以这篇文章我打算从一线实际使用的角度，把一套可直接复制的 MySQL 设计规范拆开讲清楚，覆盖命名、类型、索引、范式、约束、变更这几个核心环节，每一条都会说清楚为什么这么定，不这么定会出什么事。

2. 库、表、字段命名：大小写、分隔符与保留字这几条底线

2.1 库名和表名：小写字母加下划线，一个业务域一个前缀

命名规范是所有规范里最容易被忽视、又最容易引发连锁问题的一环。我见过不少项目，库名用驼峰，表名用大写，字段名中英混排，最后业务代码里写 SQL 时全靠 IDE 提示来补全，换一个环境就报错。

MySQL 在 Linux 上是区分大小写的，在 Windows 上默认不区分，这个差异就是埋雷的地方。如果开发同学在 Windows 本地建了一张UserOrder表，提交的 SQL 脚本到 Linux 生产环境执行，user_order是完全不同的两个对象。为了彻底绕开这个坑，我建议直接规定：

• 库名、表名、字段名统一使用小写字母，单词之间用下划线分隔。
• 同一业务域的表使用统一前缀，比如用户中心uc_、订单中心ord_、商品中心pms_，一眼就能看出表归属哪个模块。
• 表名的长度控制在 30 个字符以内，过长的表名在 ER 图和日志里都很影响阅读。
• 禁止使用驼峰命名、禁止中英文混搭、禁止大小写混用。

这里有个容易被忽略的点：MySQL 的库名表名在 Linux 文件系统里对应的是目录和文件，如果你用了大写字母，某些大小写敏感的文件系统下，备份恢复、主从切换时可能直接找不到表。我经历过一次迁移事故，就是导出导入后表名大小写不一致导致应用全部报table doesn't exist，后来统一成小写加下划线，这类问题再没出现过。

2.2 字段名的语义一致：同一个词，全世界都一个含义

字段命名最考验团队的抽象能力。同一个概念，在不同表里叫法必须一致。我建议把常用的字段名固定下来，形成一张团队内部的“字段字典”：

字段名统一的直接收益是写 SQL 不用查表结构。你看到一个created_at，不需要怀疑它有别的写法，JOIN 条件和 WHERE 条件也少了一堆低级错误。

2.3 保留字与关键词：建表前先过一遍字典

这个坑可以说是新人高频踩坑点。order、group、desc、select、rank、key、index这些都是 MySQL 的保留字或内置函数名。你建一张order表，在绝大多数场景下不报错，但在某些 SQL 写法里必须用反引号包起来，非常烦人。

规范里我要求所有表名、字段名在定稿前必须做一次保留字检查。MySQL 官方文档里有完整的保留字列表，也可以用一条 SQL 查：

SELECT * FROM information_schema.KEYWORDS;

如果字段确实需要用到类似语义的词，比如业务里就是有个字段叫rank，我建议改名成rank_no或sort_level，而不是让所有查询都背着一堆反引号。要记住：数据库对象的命名是为十年后的维护者服务的，不是为你今天写代码方便服务的。

3. 字段类型选择：整数、小数、字符和时间到底怎么定

3.1 整数类型：不用省那几个字节

MySQL 的整数类型有tinyint、smallint、mediumint、int、bigint，字节数分别是 1、2、3、4、8。很多同学在设计表时为了“省空间”把主键设成int，状态位设成tinyint(1)，这本身没错，但要务必要想清楚边界。

我见过一个表，主键用的int有符号，最大 21 亿多。业务当时觉得这辈子用不完，结果三年后达到十亿量级，被迫停机改表结构把主键换成bigint，整个过程痛苦不堪。所以从规范上我直接要求：

• 主键统一用bigint unsigned，除非你能证明这张表生命周期内数据量一定小于 21 亿。
• 状态字段用tinyint unsigned，取值范围 0~255，多状态枚举完全够用。
• 数量、计数类字段优先int unsigned，量级特别大的用bigint。
• 允许为 NULL 的数值字段，建议显式给出 DEFAULT 值，避免 NULL 参与计算时产生意外结果。

值得说明的是unsigned本身不会让性能更好，它只是扩大了正数取值范围。如果status只用 0 和 1，tinyint和tinyint(1)在存储上没有区别，显示宽度只是给客户端展示用的，不影响存储。这个认知要清楚，别被“长度”这个概念误导。

3.2 小数类型：金额和比率必须用 DECIMAL

这是最不该含糊的地方。float和double是浮点数，存在精度损失。金额字段如果用float，当你存入 0.1 时，实际可能是 0.100000001490116。十几个字段累加之后，误差就会暴露出来，对不上账。

我的规定很简单：

• 金额、价格、费率、余额等小数类型一律使用decimal。
• decimal的定义要写明精度，比如decimal(10,2)表示最长 10 位，小数点后 2 位。金额字段建议至少预留到decimal(10,2)，如果以后可能做大额交易或分账，直接上decimal(20,6)也不亏。
• 禁止用float、double存任何跟钱有关的字段。
• 小数比较、求和时注意decimal的精度与业务舍入规则是否一致，必要时在应用层统一四舍五入策略。

有人会问：那float还有用吗？有，比如一些科学计算、经纬度、统计分析中允许近似值的地方可以用。但凡是需要精确表示的业务字段，一律decimal。

3.3 字符串类型：VARCHAR 长度不是越大越好

varchar是最常用的字符串类型，它存储的是变长字符加上 1~2 字节的长度记录。新人常犯的错是把所有字符串字段都设成varchar(255)，理由是“不差这点空间”。实际上这个习惯会造成两个问题：

• varchar过大会影响索引效率。在 utf8mb4 字符集下，一个字符最多占 4 字节，varchar(255)需要 1020 字节的索引空间，而 InnoDB 单列索引最大长度默认是 767 字节（或取决于页面大小）。
• 业务上无法约束数据长度。比如订单号本来最长 32 位，你给了 255，结果上游塞进来一串 200 位的垃圾数据，入库不报错，后期查询和展示都出问题。

我这边给出的标准是：根据业务真实最大长度 + 30% 的余量来定varchar长度。比如手机号最长 11 位，我建议varchar(20)；邮箱最长常见不超过 50 位，建议varchar(64)；订单号按业务规则最长 32 位，建议varchar(50)。文本内容超过 512 字符的，考虑用text或者拆分子表。

text字段要注意：它不能在非前缀索引情况下正常建普通索引，平时也不建议拿来当查询条件。大文本搜索应该走全文索引或搜索引擎，不要指望 MySQL 在千万级text字段上做 LIKE 模糊查询还能快。

3.4 日期时间类型：首选 DATETIME，别再用时间戳

日期时间类型有date、time、datetime、timestamp、year，还有很多人喜欢用int或bigint存 unix 时间戳。我的态度很明确：新表一律使用datetime，原因有三个。

• datetime可读性好，直接就能看出来是什么时间，排查问题不用做换算。
• datetime取值范围从 1000-01-01 到 9999-12-31，足够覆盖绝大多数业务。
• 时间戳int只能表示 1970 到 2038 年，2038 问题对长周期系统而言是真实的炸弹。

timestamp也有它的归属场景：它自带时区转换，如果系统需要按用户时区展示时间，可以更灵活。但带来的问题是数据实际存的是 UTC 时间，如果周边系统时区配置不一致，很容易出现“查出来的时间差八小时”的经典事故。所以我建议默认datetime，确需时区自动转换的场景单独评审。

这里还涉及一个细节：到底字段叫什么。统一为created_at、updated_at之后，默认值也要规范。MySQL 从 5.6 开始支持DATETIME类型带默认当前时间，所以建表时可以这样写：

CREATE TABLE `uc_users` ( `id` bigint unsigned NOT NULL AUTO_INCREMENT, `nick_name` varchar(30) NOT NULL COMMENT '昵称', `created_at` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, `updated_at` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci COMMENT='用户表';

ON UPDATE CURRENT_TIMESTAMP这个特性很多人不敢用，怕时间不准。实际上 MySQL 对updated_at的更新是发生在行数据被 UPDATE 时自动刷新的，只要不是手动显式赋值，它就能保持正确。当然，如果你用了 MyBatis Plus 这类 ORM 的自动填充，可以在应用层做，两种方案取其一即可，不要跟数据库的自动更新同时生效，否则容易覆盖。

4. 主键与索引设计：让 EXPLAIN 替你说话

4.1 主键选择：自增还是 UUID，这是一道必须提前答完的题

主键设计直接决定 InnoDB 表的物理存储结构。InnoDB 是聚簇索引组织表，数据行按照主键顺序物理排布。自增主键天然是顺序递增的，插入时总是在页的末尾追加，不会导致页分裂和碎片化。这是最推荐的方式。

UUID 作为主键的问题在于它是随机字符串，插入时主键顺序不连续，极端情况下导致大量页分裂、随机 IO，写入性能断崖式下降。而且 UUID 占用 36 个字符，作为聚簇索引会让二级索引的体积成倍增大。

但有一种情况我明确建议用业务唯一键而不是自增主键：分布式场景或多系统合并数据的场景。届时自增主键可能出现冲突，用雪花算法生成的bigint主键更为合理。这也是为什么我把主键统一成bigint unsigned——雪花ID正好可以存在bigint里。

结论性建议：

• 单库单表：自增bigint主键，名统一叫id。
• 分库分表或者需要跨系统合并：应用层生成雪花 ID，存bigint unsigned。
• 禁止使用 UUID 字符串作为主键；禁止无主键表。

4.2 每一张表都必须有主键，这是底线

没有主键的 InnoDB 表，MySQL 会生成一个隐藏主键，这个隐藏主键你碰不到也不会知道，结果就是数据复制、主从切换、归档时全都变得不可控。规范必须写死：任何表都要有主键，且主键要满足非空、唯一、稳定这三个条件。

我见过有人把“业务主键”和“代理主键”搞混。比如订单表，业务上order_no是唯一的，于是直接把order_no设成主键。这在单库时代没毛病，但一旦未来要分表，order_no可能就不是全局唯一了。更稳妥的做法是：id作为代理主键，order_no上建唯一索引，两者各司其职。

4.3 索引设计：少而精，覆盖优先

索引不是越多越好。每个索引都会占用磁盘，并拖慢写入性能。我评审表结构时经常看到一张表挂了十几个索引，实际上很多是冗余的。索引设计有一条非常实用的原则：联合索引要遵循最左前缀，尽量让一条索引覆盖多个查询路径。

举一个实际例子。订单表有user_id、shop_id、status、created_at四个常用查询字段。如果分别建四个单列索引，效率远不如建两组联合索引：

KEY `idx_user_status` (`user_id`, `status`, `created_at`), KEY `idx_shop_status` (`shop_id`, `status`, `created_at`)

这样设计之后，查询“某个用户某状态下的订单按时间排序”就能完全用索引覆盖，避免文件的排序。很多人忽略的是：索引中字段的顺序决定了可用性。把区分度高的字段放前面，把范围查询字段尽量放后面，这些规则都必须写进规范，并且要求开发在提交 SQL 前跑一次EXPLAIN，确认type不是ALL、key不是 NULL。

4.4 常见索引设计记录：建立一张索引 checklist

我把索引相关的审查项做成了一张团队内必查表：

5. 范式与反范式：拆表还是冗余，必须有一个明确标准

5.1 范式是理论基础，但不能生搬硬套

教科书里讲三大范式、BCNF，很多同学记住了“要消除冗余、要拆分表”。实际业务里如果严格执行第三范式，你会发现查询时要关联七八张表，性能惨不忍睹。所以规范里我给的是混合策略：核心交易数据倾向规范化，查询密集的数据允许反范式冗余。

第三范式本质上解决的是“数据一致性”问题：一条数据只在一个地方维护，避免更新时出现多处不一致。这个思想对订单、账务、库存这些强一致场景完全适用，该拆就拆。但对于用户昵称、商品名称这种更新频率低、查询频率极高的信息，冗余到订单表里往往是更明智的。比如订单快照表里就冗余了goods_name和goods_price，因为用户下单后商家改了商品名和价格，历史订单必须显示当时的信息，这种冗余不是缺点，是业务要求。

5.2 冗余字段的边界：不可变或低频变 + 高频读

什么字段适合冗余？判断标准我总结为三句话：

1. 冗余字段的值变化频率极低，比如商品名称、下单时的收货地址。
2. 冗余字段的更新可以由明确的事件触发，且能保证最终一致。
3. 冗余带来的收益要明显，即显著减少高频查询的 JOIN 开销。

要避免冗余的是那些高频率更新的字段。比如用户积分、库存余量，这类如果到处复制一份，分布式一致性问题会让你生不如死。

5.3 大字段拆分的判断：什么时候分表，什么时候只拆字段

还有一种常见需求是单表字段过多。有的表建了七八十个字段，说实话在 MySQL 中字段多并不会直接造成性能问题，真正的问题是：一行数据过大，更新时锁的范围、缓冲池的占用都会变大。如果一个表里既有频繁访问的热点字段，又有大量很少读取的文本大字段，我建议做垂直拆分，把大文本挪到扩展表，比如user_profile_ext表，通过主键一对一关联。

水平拆分则不要在一开始就做。我的建议是：先按规范设计一个垂直可扩展的模型，单表数据量到两千万以后再考虑水平分表。过早分表带来的跨表查询、聚合统计问题远比收益更麻烦，除非你有明确的容量规划，否则不要轻易上。

6. 约束与默认值：数据库层防呆设计的最后防线

6.1 外键：默认不用，但唯一约束必须用

很多从书本上学数据库的人会惊讶于一线团队“禁用外键”的做法。原因很简单：外键约束在 MySQL InnoDB 里会带来锁竞争，高并发写入时容易成为性能瓶颈；而且一旦跨库分表，数据库外键就没法用了。业界主流方案是在应用层保证引用完整性。

但这不等于不设约束。所有业务上的唯一性，比如订单号、手机号、用户登录名，都必须建唯一索引，由数据库兜底。应用层两台机器并发插入，只有一个能成功，这是唯一索引存在的意义。我在评审时反复强调这一点：应用层可以做逻辑校验，但唯一性最终必须落在数据库约束上，这才是最后一道防线。

6.2 默认值和 NOT NULL：避免 NULL 的三态地狱

NULL在 SQL 里是一个很特殊的“三态”概念，它不等于 0，不等于空字符串，也不等于 false。对NULL做比较运算时结果依然是NULL，这会让WHERE a = NULL永真或永假，也会让COUNT(字段)统计不到 NULL 行。

我的规范是：

• 业务字段尽量全部NOT NULL，并且显式提供默认值。
• 字符串字段默认不要给NULL，给空字符串''，除非你有明确的语义需要区分“未填写”和“填空字符串”。
• 数值字段默认给 0 或业务定义的最小值。
• 时间字段默认给CURRENT_TIMESTAMP或固定时间。
• 确实需要 NULL 语义的字段，要单独评审并注释说明。

这条规定执行到位之后，应用代码里各种if (xxx == null)的空指针少掉一大半，SQL 统计也干净很多。

6.3 字段注释：写清楚是给未来同事留门

字段注释看起来不起眼，但它的价值在半年后你重新接手一个系统时完全体现。规范要求：每一张表都要有COMMENT说明表用途，每一个字段都要有COMMENT说明含义、单位、取值范围。状态字段还要额外注明每个数值代表什么含义。

如果团队的枚举定义放在代码里，那么建表 SQL 的字段注释里必须写清“0 待支付 / 1 已支付 / 2 已取消”，不要只是干巴巴写一个“状态”。这能直接减少以后大量翻代码确认枚举值的时间。

7. 字符集、排序规则与存储引擎：全局默认最容易埋雷

7.1 字符集统一使用 utf8mb4

关于字符集，我的立场非常简单：新库新表一律utf8mb4。utf8mb4是真正的 UTF-8，能完整表示 emoji 和大部分生僻汉字；老的utf8在 MySQL 中最多只有 3 字节，遇到 emoji 直接报错或乱码。

建库时就要固定：

CREATE DATABASE `your_db` DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

线上环境如果已经存在大量老表用utf8，也要排期完成字符集迁移。迁移过程需要注意索引长度问题，因为utf8mb4下索引会比utf8更长，部分表可能需要同时调整字段长度。

7.2 排序规则：unicode_ci 还是 general_ci，别选错

utf8mb4_unicode_ci和utf8mb4_general_ci都能用，差别很小，主要是排序和对某些字符的相等性判断规则。general_ci性能略好，但精确度上unicode_ci更符合 Unicode 标准。我统一推荐utf8mb4_unicode_ci，因为实际差别在常规业务里几乎感知不到，但后者在多语言场景更稳妥。

要注意的是，一张表里的字段可以单独指定排序规则，如果表排序规则和字段排序规则不一致，查询时可能出现无法使用索引的情况。所以建表语句里就统一显式写出字符集和排序规则，不要依赖实例级默认值，避免从测试环境到生产环境配置不同导致行为漂移。

7.3 存储引擎：InnoDB 是唯一选择

从 MySQL 5.7 开始，InnoDB 就是默认引擎，但规范里依然要写死：全部使用 InnoDB。理由很简单：支持事务、支持外键（虽然我们默认不用外键，但万一需要）、支持行级锁，崩溃恢复能力强，属于通用业务最稳妥的选择。

MyISAM 在只读报表类场景可能还有一点历史遗留，但新的业务表一律不许用，因为它不支持事务，表锁会导致并发写入严重串行化，一旦异常断电还容易损坏表。

8. 从设计到落地：评审流程、版本化 DDL 与常见坑

8.1 表结构评审：把规范塞进流程，靠人肉不如靠工具

规范写在文档里没人看等于零。真正能落地的办法是把评审做成强制节点。我团队的操作是：新表或表结构变更，必须走一个简短的评审流程，至少包含这几个检查项：

1. 是否遵循命名规范，有没有使用保留字。
2. 是否每条字段都有注释。
3. 索引是否能覆盖主要查询，是否存在重复索引。
4. 字段类型是否合理，有没有隐式转换风险。
5. 唯一性约束是否由数据库兜底。

另外可以用工具辅助，比如pt-online-schema-change、gh-ost来做大表 DDL，SchemaCI或自研脚本做数据库 CI 扫描，我没法推荐某一个特定工具，但核心思路是：将规范检查自动化到发布管道，不能只靠人自觉。

8.2 版本化 DDL：表结构必须跟代码一起进 Git

数据库表结构是最容易被版本管理忽视的部分。很多人改完表结构，只在测试环境执行一遍，没有留下任何痕迹。三个月后生产环境要做迁移，只能翻开发记录里零碎的 SQL 片段。

我要求所有建表、改表 SQL 必须放进项目根目录的migration目录，按版本号命名，比如V20250101__create_uc_users.sql。每次发布都从空库执行一遍所有 migration 脚本，保证环境同步。这个习惯最大的受益点是：新同事拉下代码后能快速搭建完整本地环境，测试环境和生产环境结构差异一目了然。

8.3 在线变更：大表 DDL 的锁表问题

表结构变更在 MySQL 5.6 之后支持了在线 DDL，但“在线”并不代表零风险。修改字段类型、增加索引、修改字符集这些操作，仍然可能触发表的重建，期间产生的锁和 IO 压力足以拖垮线上业务。

我给出的操作规范是：

• 单表数据量超过 500 万行的结构变更，一律使用pt-osc或gh-ost工具在低峰期执行。
• 变更前先评估磁盘空间，因为很多工具需要复制一份临时表，至少要有原表 1.5 倍的空间。
• 变更窗口设置充分的时间余量，避免 binlog 积压导致主从延迟。

这里有同学会问：为什么不能直接用ALTER TABLE？因为业务高峰期锁等待直接导致连接数打满，我踩过的教训就是：一张千万级表增加一个普通索引，在线执行的十来分钟里写请求全部阻塞，最后连接池耗尽，整个服务雪崩。从那以后，我宁愿慢一点也要用在线工具。

8.4 执行规范后最大的收益：团队沟通成本直线下降

规范最难的不是定规矩，而是坚持执行。团队里总有人说“这个字段很急，先加进去，等以后再规范”，这种口子一开，三个月后表结构又回到混沌状态。我个人的经验是：规范可以迭代，但执行不能打折。一旦发现违反规范的表，立刻排期整改，越早处理成本越低。

每次新人入职，我都会让他先读一遍数据库设计规范，然后试着评审两三张老表，指出不合规的地方。这个过程比培训效果好得多，因为他会真正意识到规范不是束缚，而是一张避坑地图。

9. 最后分享几个我自己常用的兜底技巧

写到这里，干货已经讲得差不多，我最后补充几个实际工作中非常常用、但很多人不知道的小技巧。

第一个是关于EXPLAIN的误判。很多开发习惯只看type是不是ALL，实际上type=ALL不一定完全不可接受，如果表只有几百行，全表扫描反而比走索引快。真正要警惕的是key为 NULL、rows估算值明显放大、以及Extra里出现Using filesort和Using temporary，这三个信号才说明索引设计有问题。评审时尽量把这三项也写进 checklist。

第二个是关于隐式类型转换。数据库规范里一定要强调：字段类型和查询条件类型必须一致。比如user_id是bigint，却传了个字符串'123'来查，MySQL 会将整表字段都转成字符串做比较，索引直接失效。线上查不到数据或者慢查询，一半以上是这个问题。排查方式就是看 EXPLAIN 的key是否为 NULL。

第三个是定期做一次 Schema Review。不要等到出事故再反思，我建议每两三个月由一个人通读一遍所有表的 DDL，顺手把废掉索引、注释缺失、类型不合理的表标记出来。这件事在数据量小的早期做，成本极低，收益极高。等数据量上来再改，就是每一条都要演一场刚才说的那种大表变更的惊悚剧。

我个人用了这套规范带队近十年，最大的感受不是数据库“变快”了多少，而是整个系统变得可预期了。任何一个后来者接手，不需要猜，不需要翻代码，看建表语句就能读懂业务模型。这大概就是数据库设计规范存在的真正意义吧。