lloydsheng我这两年接过不少“遗留系统”，每次打开数据库第一眼看到那种没有主键、字段名充满拼音缩写、时间字段一会有 create_time 一会有 created_at 的表，内心都会翻江倒海。MySQL 入门容易，装个环境、写几条 CRUD 谁都会，但真正决定一个项目能不能长期维护、查询能不能扛住、后续能不能顺利扩展的，往往不是业务代码，而是建表那一刻的取舍。这篇内容就想和你认真聊透 MySQL 库表设计规范，从命名、数据类型、主键、索引到公共字段的常见约定，并结合一个学生成绩信息系统的完整建表过程做演示，帮新手少走那些我当年绕了很久的弯路。
什么层次的人适合看？只要你在用 MySQL、正在写业务表、或者准备面试时回答“你怎么设计一张表”，这份内容都能对得上。老手不用往下看，但如果你是刚学会建库建表、准备正经做一个项目的阶段，我建议你把它当作一份检查清单来用。
1. 先聊聊为什么库表设计规范值得认真对待
1.1 烂表带来的后遗症有多痛
很多人觉得表设计不就是“有几个字段就建几列”嘛，等业务跑起来再改也不迟。这句话在 demo 阶段确实成立，但项目一上线，你就知道什么叫“牵一发动全身”。
先说一个特别典型的场景：字段含义不明确。我曾经接手过一个用户表，里面有 name、user_name、nickname、real_name 四个字段，代码里一会儿用这个一会儿用那个，业务逻辑根本对不上，后来花了两周梳理历史数据才搞清楚有些是历史遗留、有些是不同端写入的。如果建表时就把命名收敛好，这种问题完全不会出现。
更痛的是数据类型选错。有人把手机号设计成 int，存进去发现第一位为 0 的号码直接被吃掉，或者长度超了直接报错；有人把金额设计成 float，月底对账差出几分钱，查了三天最后发现是浮点精度问题。这类问题一旦数据量上来，几乎是灾难级的——你不可能为了修字段类型去停服，但不停服修改又容易锁表，两边都是坑。
库表设计规范和写代码的规范本质是一样的：不是为了好看，是为了降低沟通成本、减少故障、留出扩展空间。它可以不完美，但必须一致、能被理解、能演进。
1.2 这份规范适合谁来抄作业
如果你属于下面这几类人，这份规范尤其值得多看两遍：
- 刚学完 MySQL 基础语法、想正经做一个课程设计或个人项目的在校生；
- 刚入职、需要在团队现有数据库基础上继续开发的新人，你想知道字段到底该怎么加才不挨骂；
- 准备面试的开发者，因为“如何设计一张订单表”“主键用自增还是 UUID”这类问题几乎是 MySQL 面试题里的保留项目；
- 带项目但组里没有统一数据库规范的技术负责人，可以直接把后面的约定摘出去当团队草案。
而如果你已经能独立设计几十张表的业务系统，并且踩过足够多的坑，那这份内容对你来说更多是查漏补缺，不必逐字精读。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 库和表的命名规范：别让后任骂娘
2.1 一套规则吃遍所有对象
命名这件事，不同团队习惯不同，没有绝对的对错，但没有规则一定出乱子。我的建议是按下面这一套底线规则来约束库名、表名、字段名。
一，全部小写。MySQL 在 Linux 下默认对表名分区是大小写敏感的，Windows 和 macOS 下又不敏感，同一条 SQL 换环境跑结果可能不一样。为了避免这种“环境差异”，新建的库、表、字段一律小写。
二，用下划线分词，不要用驼峰，也不要写拼音缩写。比如用户登录记录表，user_login_log 一眼就能看懂，userLoginLog 也能接受，但 yhdljl 这种纯拼音缩写，换个人来看基本等于乱码。
三，库名用业务域命名，不建议叫 test、aaa。一个中型系统里通常有用户域、订单域、支付域，库名最好能体现归属，例如 shop_user、shop_order、shop_pay，后期做权限隔离、数据迁移都会方便很多。
四，表名尽量用业务意义的复数或单数名词，例如 student、course，不要加 sys_、t_ 这类和业务无关的前缀，除非团队已经统一规定。
下面列一个简单的对照表，告诉你我看到什么样的名字会觉得想给这个开发者加分：
| 对象 | 推荐 | 不推荐 |
|---|---|---|
| 用户基础信息表 | user_account |
users、u、用户 |
| 订单表 | order_info |
orderss、OrderInfo |
| 用户手机号字段 | mobile |
phone、shouji |
| 创建时间字段 | create_time |
created、cj_time |
| 逻辑删除字段 | deleted |
isdelete、flag |
2.2 保留字和大小写是要命的暗坑
很多新手第一次设计表，习惯把字段命名为 name、key、value、desc、order、group。这些单词在英语里很常见，但在 MySQL 里属于保留字或关键字，使用的时候必须用反引号包起来。包一次两次没事，但如果在代码里每个查询都要写反引号，或者框架自动生成 SQL 时忘了处理，线上就会冷不丁报语法错误。
所以建表之前养成一个习惯：把要用的字段名丢到 MySQL 官方文档的保留字列表里过一遍。拿不准的 key、desc、order、rank、source 这些干脆直接改名，避免以后所有 SQL 都要背“反引号债”。
顺便说一句大小写问题。字段名、表名不要用驼峰还有一个实际原因：MySQL 的 lower_case_table_names 参数在不同操作系统上默认值不一样，Linux 默认为 0（区分大小写），Windows 默认为 1（不区分）。如果开发时在 Windows 建了一张 OrderInfo 表，提交代码后 Linux 测试环境查 orderinfo 就会报“表不存在”。全员小写下划线，能从根上避开这个环境不一致的坑。
2.3 字段命名要做到“见名知义”且保持统一
字段命名最容易犯的错不是用错单词，而是同一个含义在不同表里叫法不一致。比如“创建时间”，一张表叫 create_time，另一张表叫 gmt_create，还有一张表叫 created_at，写 JOIN 时你不得不反复去查表结构，非常折磨。
这里的建议是：一旦团队定了规范，所有新表都按统一后缀走。比如时间字段统一叫 create_time、update_time，那么所有表都这么叫；状态字段统一用 status，就不要另一张表叫 state。字段含义清晰比所谓的“高情商命名”重要得多。
另外，布尔字段不要叫 is_deleted 然后存字符串 'Y'/'N'，这种设计会让索引失效、统计麻烦。建议用 tinyint(1)，0 表示否、1 表示是，字段名直接用 deleted 这种肯定式动词，避免 is_ 前缀带来的“0 是删除还是未删除”的思考成本。
提示：命名不是考试，不是为了展示英语词汇量。用最常见的单词，把含义表达清楚，后人才不会对着你的表骂街。
3. 字段的数据类型：一步选错，长期遭殃
3.1 整数类型与 int(5) 这个经典误区
MySQL 提供的整数类型有 tinyint、smallint、mediumint、int、bigint，区别是存储字节数和取值范围不一样。设计时最常见的问题是“无脑 int”，哪怕只存 0