企业官网建设流程全解析

MySQL系列写到第三篇了，这正好对应课程进度的 3/12。前两篇我们把 MySQL 的安装、客户端连接、基本概念全部捋了一遍，从这一篇开始正式进入“写 SQL”的阶段。今天要聊的是 SQL 语法基础、DDL 语法，以及数值类型。很多自学 MySQL 的同学容易跳过这三块直接去背 SELECT 和 JOIN，结果一到建表就凭感觉乱来，字段类型选错，表结构设计成一团乱麻，后面改起来欲哭无泪。这篇文章就是为这个准备的：适合刚学数据库的入门读者，也适合写过几年 SQL 但从来没系统梳理过 DDL 和数值类型细节的开发同学，看完能直接照着操作，把自己手头的表结构重新整理一遍。

SQL 语法本身不难，难的是建立“规则意识”。DDL 是数据定义语言，负责建库、建表、改表、删表，它决定了数据以什么结构存在；数值类型则是字段设计里最容易被低估的环节，一个 int、decimal、float 选错了，后面轻则浪费存储空间，重则出现金额对不上账、库存算错这类线上事故。这篇我就把语法规则、DDL 操作和数值类型一次性讲透。

1. SQL 语法基础，先搞清楚你在写什么

1.1 SQL 四大分类，别再把所有命令混成一锅粥

接触 MySQL 第一件要做的事，不是在编辑器里狂敲 SELECT，而是先搞清楚 SQL 语句到底分几类。SQL 按功能分成四类：DDL（Data Definition Language）、DML（Data Manipulation Language）、DQL（Data Query Language）、DCL（Data Control Language）。新人最常犯的错，是觉得只要写了 SQL 就是“查数据”，其实查数据只是其中一个分支。

我用盖房子来打比方。DDL 是打地基和砌墙，决定房子有几层、每间房多大，对应 CREATE、ALTER、DROP 这些建库建表改表删表语句；DML 是往里搬家具、摆东西，对应 INSERT、UPDATE、DELETE，负责操作数据；DQL 是站在屋里清点家当，对应 SELECT 查询；DCL 是给谁配钥匙、谁能进哪间房，对应 GRANT、REVOKE，负责权限管理。MySQL 日常开发 80% 的时间在写 DQL 和 DML，但真正决定一个系统底子好坏的，反而是 DDL。

把这四类分清楚有一个实际好处：面试和文档里经常出现“DDL”“DML”这样的词，分不清会非常被动。更重要的是，MySQL 对某些语句有执行限制，比如事务回滚对 DDL 无效，你一旦把 DROP 当成 DELETE 用，误删了表，连回滚的余地都没有，这属于原则性区别，后面我会专门展开讲。

1.2 语法书写规则，以及一条 SQL 的执行顺序

DDL 语法本身不复杂，但书写规则一定要在最开始养成习惯。MySQL 对关键字不区分大小写，SELECT 和 select 都能跑，但团队协作里通常约定关键字大写、表名字段名小写，这样日志里看长 SQL 一目了然。每条完整语句以分号结束，在命令行客户端里忘打分号回车，MySQL 会认为语句没结束，继续等待输入，新手经常在这个地方愣住。

注释有两种常用写法：单行注释用两个短横线加一个空格（-- 注释内容），或者用井号（# 注释内容）；多行注释用 /* 注释内容 */。写复杂的 DDL 脚本时，我强烈建议每个字段都加注释，后面维护的人会感谢你。MySQL 还支持在语句里加版本信息、创建人信息，这些讲究在团队规范里可以再细化。

关于执行顺序，虽然 DDL 不像 SELECT 有复杂的谓词逻辑，但理解 MySQL 的解析顺序很重要。SELECT 语句的书写顺序是 SELECT、FROM、WHERE、GROUP BY、HAVING、ORDER BY、LIMIT，而实际执行顺序是 FROM、WHERE、GROUP BY、HAVING、SELECT、ORDER BY、LIMIT。这意味着你在 SELECT 里定义的别名，不能直接在 WHERE 里使用，因为 WHERE 先于 SELECT 执行。这类规则属于“踩过才知道疼”的坑，先有这个意识，后面写复杂查询能少走很多弯路。

2. DDL 语法拆解：建库、建表、改表、删表一次理清

2.1 库级 DDL：字符集和排序规则必须在第一步定死

DDL 从库级操作开始。创建数据库的标准语法是 CREATE DATABASE IF NOT EXISTS 库名 DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci。这里有两个极其容易忽略的参数：CHARACTER SET 是字符集，COLLATE 是排序规则。字符集决定数据库能存什么字符，utf8mb4 是现在唯一推荐的选择，它兼容完整的 Unicode 字符，连emoji 也能存；utf8mb4_unicode_ci 则是基于 Unicode 的排序规则，对多语言支持更准确。

为什么说必须在第一步定死？因为数据库、表、字段三级都可以单独设置字符集，建库时定下来，后面建表时如果没显式指定，会自动继承库的设置。最怕的是库里建表时手滑设成了 latin1 或 utf8mb3，存中文和特殊符号时直接报错，或者插入数据没问题、查询结果变成乱码，这种问题经常发生在老系统迁移的现场，排查起来非常折磨人。使用 ALTER DATABASE 可以修改库的字符集，但只对后续新建的默认继承生效，存量表如果已经是错误字符集，改完依旧乱给你看。

DROP DATABASE 的威力要特别强调：一条语句直接删掉整个库，连带库里所有表和数据，而且不经过事务机制，无法回滚。我的习惯是任何 DROP 语句在正式环境执行之前，先看一眼有没有备份文件，再把要删的库名 SELECT 出来确认一遍，宁可让人觉得我啰嗦，也不愿意图快出事故。

2.2 表级 DDL：CREATE TABLE 的完整结构长什么样

CREATE TABLE 是 DDL 里的重头戏。语法骨架如下：CREATE TABLE 表名（字段名 数据类型 [字段约束] [注释]，...），最后带表选项 ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='表注释'。字段约束包括 NOT NULL、DEFAULT、PRIMARY KEY、UNIQUE KEY、AUTO_INCREMENT、COMMENT 等。新手最容易漏掉的是 COMMENT，建表时偷懒不写注释，三个月后连你自己都记不清这个字段是干嘛的，更别说同事了。

表选项里 ENGINE 指定存储引擎，现阶段无脑选 InnoDB。原因很明确：它支持事务、支持行级锁、支持崩溃恢复和外键约束，MyISAM 虽然在特定只读场景下查询快一点，但锁表、不支持事务这两条在业务系统里就是硬伤。DEFAULT CHARSET 继续沿用库级的 utf8mb4，不要单独换成其他字符集，保持继承关系能让排查乱码问题时少一个变量。

给字段定类型和约束的时候，要遵循“够用且留余量”的原则。比如主键，我倾向于用 BIGINT UNSIGNED AUTO_INCREMENT，而不是 INT，因为业务量增长比想象中快，INT 上限 21 亿看着很多，但对一个活跃用户系统来说几年就能触顶，到时候再改主键类型，成本高到让你怀疑人生。自增主键配合 AUTO_INCREMENT 使用时，MySQL 自动生成连续值，不需要也不应该手动指定。

2.3 修改表结构：ALTER TABLE 的四种核心操作

表结构不是一次建好就永远不变的，业务迭代必然带来字段调整。ALTER TABLE 有四种最常用的子操作：ADD 增加字段、MODIFY 修改字段类型和约束、CHANGE 重命名字段同时修改类型、DROP 删除字段。它们的语法分别是：

-- 增加字段 ALTER TABLE student_score ADD COLUMN class_no VARCHAR(10) NOT NULL DEFAULT '' COMMENT '班级编号' AFTER student_name; -- 修改字段类型和约束（不能重命名） ALTER TABLE student_score MODIFY COLUMN student_name VARCHAR(30) NOT NULL COMMENT '学生姓名'; -- 重命名字段并修改类型 ALTER TABLE student_score CHANGE COLUMN student_name student_name VARCHAR(50) NOT NULL COMMENT '学生姓名'; -- 删除字段 ALTER TABLE student_score DROP COLUMN class_no;

ADD 里的 AFTER 关键字控制新字段加在哪个已有字段后面，默认加在最后。这看似无关紧要，但在表字段多、通过 SELECT * 查看数据时，字段顺序会影响日常使用体验，所以我会尽量按业务语义排好。MODIFY 和 CHANGE 的区别经常在面试里被问到，记住一句话：只是改类型和约束用 MODIFY，顺便要改字段名才用 CHANGE。CHANGE 的后半部分必须把新字段名和数据类型都写全，漏掉类型会直接报语法错误。

这里要提一个重要认知：ALTER TABLE 在 InnoDB 里不一定是瞬间完成的。MySQL 5.6 以后支持在线 DDL，但加字段、改字段类型这类操作仍然需要重建表或修改元数据，表数据量很大时执行时间可能很长，而且会带来额外负载。所以在业务低峰期执行改表操作，执行前备份，这是 DBA 和资深后端的基本素养。

2.4 DROP 和 TRUNCATE：看着像 DELETE，性质完全不同

DELETE FROM 表名是 DML，可以带 WHERE 条件删指定行，走事务，可以回滚；TRUNCATE TABLE 表名是 DDL，直接把表清空，保留表结构，但不可回滚，而且会重置自增计数器；DROP TABLE 表名则是连表带结构一起删掉。这个区别我能用一整节来讲，因为线上事故里最惨烈的往往是把 TRUNCATE 或 DROP 当成 DELETE 用了。

从执行效率上看，TRUNCATE 比 DELETE 不带 WHERE 快得多，因为 DELETE 是逐行标记删除并记录日志，TRUNCATE 是直接释放存储空间。但效率优势换来的是安全性缺失，误删之后没有任何后悔药。我的实践原则是：任何涉及 TRUNCATE 和 DROP 的语句，执行前必须先在测试库验证一遍，或者干脆让专人复核脚本，这种级别的手误谁都担不起。

3. 数值类型：字节、范围与精度，每一个都影响命运

3.1 整数类型：从 TINYINT 到 BIGINT 怎么选

MySQL 提供五种整数类型：TINYINT、SMALLINT、MEDIUMINT、INT、BIGINT。它们的存储字节数和有符号范围分别是：TINYINT 1 字节，范围 -128 到 127；SMALLINT 2 字节，范围 -32768 到 32767；MEDIUMINT 3 字节，范围 -8388608 到 8388607；INT 4 字节，范围 -2147483648 到 2147483647；BIGINT 8 字节，范围 -9223372036854775808 到 9223372036854775807。加 UNSIGNED 后上限翻倍，比如 INT UNSIGNED 可以到 4294967295。

选型逻辑不是拍脑袋。性别、状态、开关这类取值有限的字段，用 TINYINT 足够，一个字节省到极致；年龄、层级、数量这类正常业务量级，用 SMALLINT 或 MEDIUMINT；而主键、订单号、用户 ID 这种会无限增长的核心标识，必须用 BIGINT。有人觉得 INT 上限 21 亿够用，但一旦遇到分布式场景、多系统数据合并，INT 触顶迁移的惨剧我见过不止一次，主键无脑用 BIGINT 是最稳妥的选择。

这里必须破除一个流传极广的误解：INT(11) 里的 11 不是“最多只能存 11 位数字”，而是显示宽度。它只在配合 ZEROFILL 属性时才起作用，比如 INT(5) ZEROFILL 存了 1，查询会显示成 00001，不影响真实存储范围。存储范围只由 INT 本身决定。很多人被旧教程误导，以为 INT(11) 比 INT(9) 存得多，这是错的，两者的取值范围完全一样。

UNSIGNED 的使用需要谨慎。它表示非负整数，适合年龄、数量这种天然不可能为负的字段，但做算术运算时要特别注意，两个 UNSIGNED 字段相减，结果如果为负，会变成一个巨大的正数。曾经有开发同学用 UNSIGNED 存库存，在做 1 减 2 的运算时直接得出 4294967295，排查了半天才发现是无符号溢出，这个坑我会在常见问题里再讲一遍。

3.2 DECIMAL 定点数：钱和精确计算的唯一选择

如果字段要存金额、单价、精确计量值，必须用 DECIMAL，它是定点数，在指定小数位内是精确存储的。语法是 DECIMAL(M, D)，M 是总位数，最大 65，D 是小数位数，最大 30，例如 DECIMAL(10, 2) 表示总长 10 位，小数占 2 位，整数部分最多 8 位。DECIMAL 的存储不是按字节简单换算的，底层把十进制数字打包存储，大约每 9 位数字用 4 字节，但日常使用不需要抠这么细，只要记住它精确、适合金额就够了。

为什么金额不能用 FLOAT 或 DOUBLE？因为浮点数在二进制里无法精确表示所有十进制小数，0.1 在二进制中是无限循环小数，经过多次运算累积误差，最终导致金额偏差。银行账目差一分钱都是事故，所以行业规范就是金额一律 DECIMAL。DECIMAL(10, 2) 能表示的最大值是 99999999.99，设计表结构时要先估算单笔金额上限，如果业务涉及大额资金，把 M 放大到 14 或 16 位。

使用 DECIMAL 还有个细节：插入数据时小数位不足会自动补零，如果小数位超出 D 的范围，MySQL 会四舍五入而不是报错（严格模式下 sql_mode 会影响这个行为）。所以在建表时设定合理的 D 值非常重要，账务场景一般 D=2 就够了，利率或汇率场景可能需要 D=4 到 D=6，定 D 之前想清楚业务需要保留几位小数，后面改字段类型又是一轮成本。

3.3 FLOAT 和 DOUBLE：能用但别拿来算账

FLOAT 和 DOUBLE 分别是单精度和双精度浮点数，占 4 字节和 8 字节。FLOAT 大约能保证 7 位有效数字，DOUBLE 约 15 到 16 位有效数字。它们适合科学计算、统计指标、可以容忍微小误差的连续值，例如温度、坐标、百分比。MySQL 也支持 FLOAT(p) 语法，p 表示需要的精度位数，当 p 在 0 到 24 之间时按 FLOAT 处理，25 到 53 时自动转成 DOUBLE，这个语法日常用得少，了解即可。

浮点数最大的坑是在等值比较上。直接 WHERE float_col = 0.3 经常查不到数据，因为存储结果可能接近 0.300000004，带上一个微小误差，等值匹配就失效了。我见过一个统计系统用 DOUBLE 存用户评分，最后报表里 3.8 分显示成 3.7999999，虽然前端可以四舍五入处理，但底层数据不干净，后患无穷。浮点数的正确使用方式是配合范围查询，比如查询 0.299 到 0.301 之间的值，而不是精确等于。

我踩过一次很深的教训：一个订单系统早期为了图方便，单价和数量都用 DOUBLE 存储，上线半年后财务对账总差几毛钱。逐个排查发现是大量订单在计算小计和总额时产生了累积误差，虽然每单差不到一分钱，但千万单量一放大，误差就变成了一笔对不上的账。最后把金额字段全部改成 DECIMAL，重建相关表才稳住。从那以后我的原则就一条：涉及钱的字段绝对不用浮点类型。

3.4 数值类型选型速查表

为了直观起见，我把日常建表实践中的字段类型选择整理成一个速查表：

这里顺便说一下 BOOL：MySQL 的 BOOLEAN 类型其实是 TINYINT(1) 的同义词，存 0 表示假，非 0 表示真。建表时写成 BOOLEAN 合法，但 SHOW CREATE TABLE 之后你会看到底层还是 TINYINT(1)，所以不用纠结，按爱好用就行。

4. 实操：从零设计一张学生成绩表并完成 DDL

4.1 需求分析与表结构设计思路

只说理论容易飘，我拿一张实际开发中常见的“学生成绩表”完整走一遍流程。假设需求是：记录学生学号、姓名、性别、出生日期、语文/数学/英语三科成绩、总分，以及创建和更新时间。需要支持按学号唯一查询、按姓名索引查询。

根据前面讲的选型逻辑，学号用 VARCHAR(20) 存字符串编号，姓名用 VARCHAR(50)，性别用 TINYINT（1 男、2 女、0 未知），出生日期用 DATE，三科成绩用 DECIMAL(5,2)（因为成绩最多 999.99，足够覆盖 0 到 100 分加小数点后两位），总分字段我用 MySQL 的生成列，由三科成绩自动计算，避免应用层手动维护导致不一致，创建和更新时间用 DATETIME 并配合默认值。主键用 BIGINT UNSIGNED AUTO_INCREMENT，这是最关键的一步，打牢地基。

这里有个设计点值得说明：为什么不把三科成绩合并成一个 JSON 字段？合并字段在查询和索引上非常被动，比如想统计数学平均分、按语文成绩排序，JSON 字段处理起来绕一大圈，而且性能远不如独立字段。表设计时“符合关系模型直觉”通常是好设计，贴合业务查询路径去设计字段，后续写 SQL 会非常顺手。

4.2 完整建表 SQL 与字段讲解

根据上述思路，完整建表 SQL 如下：

CREATE DATABASE IF NOT EXISTS school_mgmt DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; USE school_mgmt; CREATE TABLE student_score ( id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT COMMENT '主键', student_no VARCHAR(20) NOT NULL COMMENT '学号', student_name VARCHAR(50) NOT NULL COMMENT '姓名', gender TINYINT NOT NULL DEFAULT 1 COMMENT '性别 1男 2女 0未知', birth_date DATE NOT NULL COMMENT '出生日期', chinese_score DECIMAL(5,2) NOT NULL DEFAULT 0.00 COMMENT '语文成绩', math_score DECIMAL(5,2) NOT NULL DEFAULT 0.00 COMMENT '数学成绩', english_score DECIMAL(5,2) NOT NULL DEFAULT 0.00 COMMENT '英语成绩', total_score DECIMAL(7,2) GENERATED ALWAYS AS (chinese_score + math_score + english_score) STORED 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_student_no (student_no), KEY idx_name (student_name) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci COMMENT='学生成绩表';

逐段讲解。id 主键无符号自增，不用担心负数问题。student_no 加非空约束，因为学号是业务标识，不能为空；同时建唯一索引 uk_student_no，保证学号不重复。gender 用 TINYINT，默认值 1，避免插入时漏传。三科成绩用 DECIMAL(5,2)，范围上限 999.99，对普通考试分数绝对够用。total_score 是生成列，STORED 表示物理存储，查询时直接读值，性能好，且数据库自身保证一致性。

created_at 和 updated_at 的写法是我强烈推荐的范式：创建时间默认取当前时间，更新时间在每次 UPDATE 时自动刷新到当前时间。它省掉了应用层手动维护这两个字段的麻烦，而且审计数据时非常可靠。实际使用中，几乎所有业务表我都建议带上这两个字段，这是一个成本极低、收益极高的习惯。

4.3 建表后的三类常见调整操作

表建完不代表不能动，业务总会提出新需求。实操中我常用三类调整。第一类是新增班级字段：

ALTER TABLE student_score ADD COLUMN class_no VARCHAR(10) NOT NULL DEFAULT '' COMMENT '班级编号' AFTER student_name;

第二类是修改字段宽度，比如发现姓名有人的名字超过 50 个字符（虽然少见但人外有人），用 MODIFY 改大：

ALTER TABLE student_score MODIFY COLUMN student_name VARCHAR(80) NOT NULL COMMENT '姓名，最长80字符';

第三类是新增一个状态字段用于逻辑删除：

ALTER TABLE student_score ADD COLUMN is_deleted TINYINT NOT NULL DEFAULT 0 COMMENT '删除标记 0未删 1已删';

这三类操作覆盖了日常 90% 的改表需求。执行完我习惯马上用 SHOW CREATE TABLE 表名查看建表语句，确认变更生效且没引入意外的问题。这个验证步骤虽然基础，但能挡住很多手滑操作。

4.4 查看表结构的正确姿势

查看表结构有两条命令：DESC 表名，输出精简的字段列表，适合快速浏览；SHOW CREATE TABLE 表名，输出完整建表语句，适合核对约束、字符集、生成列等细节。我强烈建议每次执行完 DDL 后，用 SHOW CREATE TABLE 复核一遍，它会把所有默认值、注释、索引都展开，任何不符合预期的隐性设置都能现形。

另外可以用 SHOW INDEX FROM 表名 查看索引信息，确认唯一索引、普通索引是否符合预期。索引不是越多越好，每个索引都会拖慢 INSERT、UPDATE、DELETE 的速度，这张演示表里学号唯一索引和姓名普通索引都是基于实际查询频率加的，没有过度设计。

5. 常见问题与避坑实录

5.1 INT(11) 和 UNSIGNED 的经典翻车现场

有一个真实场景让我印象很深。某个开发同学建订单表时把订单号字段设计成 INT(10)，因为他在教程里看到“10 位数字”就以为上限是 10 位，结果订单量过了 10 亿后字段溢出，插入直接报错，数据写不进去。后来排查才发现 INT(10) 和 INT 的存储范围完全一样，都是 21 亿多，根本不存在“改大括号里的数字就能扩容量”的操作。正确的做法是一开始就使用 BIGINT，而不是事后想办法补救。

UNSIGNED 的溢出坑同样常见。之前提到库存字段用 INT UNSIGNED，做减法时如果结果为负数，MySQL 不会报错，而是把结果变成 4294967295 这种巨大的正数，导致库存不降反升。这个问题在开发环境数据量小的时候很难暴露，一旦线上真实数据触发就会非常诡异。我的建议是尽量避免无符号类型做日常算术运算，要么老老实实用 SIGNED 并配合代码层判断，要么在 SQL 里用 CAST 转成有符号类型后再计算。

5.2 DECIMAL 和浮点数混用的精度事故

一旦表里出现 DECIMAL 与 FLOAT/DOUBLE 直接做加法或乘法，精度一定会出问题。比如一个字段存单价用 DECIMAL，另一个字段存折扣率用 DOUBLE，两者相乘，结果被 MySQL 转成 DOUBLE 计算，误差随之引入。这种混用的隐蔽性极强，看单笔结果几乎发现不了，累计到月末对账时才爆发。我的原则是同一条算式里所有参与计算的数值字段，要么全是 DECIMAL，要么全是浮点数，绝不能混搭。

另一个细节是 DECIMAL 的四舍五入行为。默认情况下，插入 DECIMAL(5,2) 字段一个 1.999 时，MySQL 会先按小数位处理成 2.00。这在某些需要严格保留小数位并做“截断”而非“四舍五入”的业务里会造成偏差。如果需要截断，可以在 SQL 里用 TRUNCATE 函数预处理，也可以在应用层处理后再入库，总之不能依赖数据库的默认行为。

5.3 ALTER TABLE 大表操作的连锁反应

对大表执行 ALTER TABLE 加字段或改类型，即便支持在线 DDL，也可能带来主从延迟、磁盘空间争抢、CPU 飙高。尤其改字段类型，MySQL 大概率需要重建表，把原表数据完整拷贝一遍，这个过程的耗时和数据量成正比。有一次我们在一个几亿行的表上直接执行 MODIFY COLUMN，跑了接近二十分钟，期间复制出来的临时表占用大量磁盘空间，差点把磁盘打满。

对这类操作，我现在的标准流程是：先在测试环境用同量级数据做压测，评估耗时；再确认磁盘剩余空间大于原表大小；最后在业务低峰期执行，并且全程监控从库延迟。如果条件允许，宁可新建一张新表，用双写或改名替换的方式完成变更，也不在大表上直接 ALTER。小团队没条件搞太复杂方案的话，至少要记得执行前备份。

5.4 保留字、字符集和默认值这些钉子

表名或字段名撞上 MySQL 保留字是新手高频报错点。比如给表起名 order，给字段起名 desc，都是保留字，直接执行会语法报错。解决方式是尽量避开保留字，实在避不开就用反引号包起来：order、desc。但带着反引号写半年 SQL 真的很痛苦，所以建表之初就要规避。

字符集导致乱码的问题属于“看起来像数据坏了，其实没坏”。库、表、字段任何一级字符集不一致，插入正常但查询乱码。诊断方式是用 SHOW CREATE TABLE 查看每一级的字符集设置，逐层对齐到 utf8mb4。另外连接层也要注意，应用连接串里可以显式指定 characterEncoding=utf8mb4，避免连接层默认字符集把 utf8mb4 数据截断。

还有一些默认值的细节约束。在 MySQL 5.7 之前，BLOB/TEXT 字段不能有默认值，表达式默认值（比如 DEFAULT (uuid())）是 MySQL 8.0 才支持的。如果用了老版本却写出了新语法，执行时要么报错要么行为不一致，所以建表前确认版本特性很重要。

5.5 表注释和字段注释别偷懒

这一条虽然不涉及报错，但算我强烈建议的经验。建表时顺手写 COMMENT，成本几乎为零，收益在半年后翻旧代码时才会体现。一个没有注释的字段，对任何人来说都是黑盒，猜错了业务含义，后续逻辑写错就是事故。我的习惯是每个字段都写注释，约束含义、取值范围、枚举含义全都写清楚。

最后再分享一个我个人的实操体会：DDL 是数据库设计中最不应该“赶时间”的部分。表结构一旦发布出去，后续改动要付出数倍的维护成本，所以建表前多问自己几个为什么：这个字段真的需要吗？数值类型有没有选错？索引是否合理？宁可多花十分钟思考，也不要将来花十个小时迁移数据。数值类型这块，选型没有绝对的对错，但你要能说出每个选择背后的理由，这是区分“会写 SQL”和“懂数据库”的分水岭。