企业官网建设流程全解析

MySQL 8.0 的基本数据类型，听起来只是建表时随手填的一个类型，实际上却决定了查询能不能走索引、数据准不准、后期改表要熬几个夜。我见过不少项目一开始不重视类型，等到表里有几千万行时想把INT改成BIGINT、把VARCHAR改成TEXT，才发现一次ALTER TABLE能把整张表锁到业务超时。这篇内容，我按 MySQL 8.0 的实际情况把基本数据类型完整拆一遍，覆盖整数、小数、字符串、日期时间、JSON、ENUM/SET，以及建表和排障过程中的坑，适合正在学 MySQL 的新手，也适合正在做数据库建模和版本迁移的开发者。

1. 动手建表前，先把类型这件事想清楚

1.1 类型选错的代价，从来不是事后改一行 DDL

MySQL 8.0 虽然对 DDL 做了不少优化，比如ALGORITHM=INSTANT可以快速增加列，但当你需要修改已有列的类型时，大部分情况下还是要把表复制一遍或者重建索引。几百万行的表可能还能忍，几千万行的主表一旦触发全表重建，主从延迟、磁盘 IO、CPU 飙升会一起出现，业务查询秒级超时是很正常的。

我以前处理过一次金额字段从FLOAT改成DECIMAL(10,2)的迁移，原因是订单对账永远差几分钱，查到最后是浮点精度问题。当时只能用脚本分批刷数据，白天不敢动，凌晨窗口执行，前后折腾了两个通宵。这件事给我最大的教训就是：类型是表结构的“地基”，第一版就选错，后面要付出的成本远超建表时多花五分钟思考。

1.2 从三个维度看一个字段类型

看一个类型合不合适，不要只凭“这个类型我见过”。我一般会从三个维度追问：

• 存储维度：这个类型占多少字节，会不会让行变胖，进而影响 InnoDB 页缓存和索引体积。
• 语义维度：MySQL 拿到这个值之后怎么比较、怎么排序，比如字符串"123"按字典序排，数字123按数值序排，结果完全不一样。
• 行为维度：这个类型的默认值、时区、隐式转换规则是什么。比如TIMESTAMP会跟随会话时区变化，DATETIME不会，这种差异线上很常见。

如果三个维度都答清楚了，类型基本不会选错。反过来，只背几个类型的字节数，遇到实际问题依然会翻车。

1.3 MySQL 8.0 在数据类型上到底改了什么

MySQL 8.0 和 5.7 在数据类型上最直接的区别，首先是默认字符集变成了utf8mb4，排序规则默认用utf8mb4_0900_ai_ci，而不是老的utf8mb4_general_ci。其次，整数后面的显示宽度，比如INT(11)，在 8.0 里已经废弃，写不写都不影响存储和范围。再有就是CHECK约束从 8.0.16 开始真正强制生效，JSON类型和函数索引也变得更实用，DATETIME默认值还可以写表达式。

如果你是从 5.7 迁过来的老手，我建议你重新看一眼建表语句，把utf8改成utf8mb4，把列上那种int(11) zerofill的旧写法清掉。别小看这些细节，字符集和排序规则不一致，往往是联表查询报Illegal mix of collations的根源。

2. 数值类型：为“数”选对座位

2.1 整数类型，一张表看清范围

MySQL 8.0 里整数类型有五种，差别主要在字节数和取值范围，直接看表最直观：

很多人喜欢“保守”地用INT当主键，但现在的订单量、用户量涨起来非常快，一旦INT自增超过 21 亿，主键直接满。如果是新表，主键我推荐直接BIGINT UNSIGNED，别等以后再来一次痛不欲生的主键类型迁移。

对于状态位这种字段，TINYINT就够了。比如订单状态用 0 到 5 表示，完全不需要INT，更不需要VARCHAR。INT占 4 字节，是TINYINT的四倍，一个表里如果到处都是INT，InnoDB 的聚簇索引会膨胀很多。

2.2 小数到底用 FLOAT、DOUBLE 还是 DECIMAL

这是金额场景最容易踩的坑。FLOAT和DOUBLE是浮点数，内部按二进制近似存储，所以会出现0.1 + 0.2不等于0.3的问题。做科学计算、统计数据时精度要求不高，可以用DOUBLE；但涉及钱、余额、税率、汇率，必须用DECIMAL。

DECIMAL(M,D)的M表示总位数，D表示小数位数。比如DECIMAL(12,2)，意思是整数部分 10 位，小数部分 2 位，最大能存 9999999999.99，一般订单总额完全够用。DECIMAL在 MySQL 内部按字符串存储，不是二进制浮点，所以才能保证精度。

还要注意，DECIMAL的精度上限是M=65，D=30，如果业务需要超过这个精度，就别硬塞给数据库字段，考虑换存储方案。另外，两个DECIMAL运算时计算结果可能超出原列精度，比如SUM(amount)的结果精度会比单列更大，应用层接收时记得留出余量。

2.3 UNSIGNED、ZEROFILL 和显示宽度

UNSIGNED本身没问题，它能让数值范围往正方向扩大一倍，适合明确不会有负数的列。但要注意，两个UNSIGNED列做减法时如果结果为负数，会直接报错，提示BIGINT UNSIGNED value is out of range。这种坑在存储过程或者动态 SQL 里很容易踩到，建议运算前先CAST成有符号类型。

ZEROFILL和显示宽度是老教程里的常见写法，比如INT(10) UNSIGNED ZEROFILL。MySQL 8.0 已经明确不鼓励这种用法，显示宽度不会限制存储大小，只会在ZEROFILL时补零。新代码里不要写，看到旧代码也建议在重构时去掉。

2.4 主键和 ID 类型，别给自己留隐患

主键类型选择直接影响写入性能和数据容量。用自增BIGINT是最稳的方案，尤其 InnoDB 聚簇索引本身要求主键尽量顺序递增，乱序的 UUID 字符串会让 B+ 树频繁分裂，写入性能下降明显。

如果你因为业务需要不得不用 UUID，也别直接存VARCHAR(36)。MySQL 8.0 提供了UUID_TO_BIN()函数，可以转成BINARY(16)，同样 36 个字符的 UUID 用 16 字节就存下来了。查询展示时再用BIN_TO_UUID()转回来，存储和索引体积都小很多。

3. 字符串与文本：远不止 VARCHAR(255)

3.1 CHAR 和 VARCHAR，定长与变长的真实差异

CHAR是定长字符串，VARCHAR是变长字符串。CHAR(10)定义后逻辑上固定 10 个字符，存储时如果内容短，会在结尾补空格；读取时 MySQL 又默认把尾部空格去掉。所以适合存国家代码、MD5 哈希、加密摘要这类长度完全固定的值。

VARCHAR(M)里M是字符数，不是字节数。它需要在存储数据之外加 1 到 2 个字节记录长度，如果列的内容不超过 255 字节，加 1 个字节；超过 255 字节，加 2 个字节。定义长度时别习惯性写 255，先问自己这个字段真正的上限是多少。用户昵称VARCHAR(32)通常就够了，VARCHAR(255)只会让每行和索引变大。

3.2 字符集、行大小和 TEXT/BLOB 的限制

MySQL 8.0 默认字符集是utf8mb4，一个字符最多占 4 字节。InnoDB 单行最大存储大小大约是 65535 字节，所以并不是你想定义多大就能多大。如果一个表里有好几个很大的VARCHAR列，很可能会报Row size too large错误。遇到这种情况，长文本应该拆到TEXT或只保留摘要，明细内容走文件存储对象存储。

TEXT家族有TINYTEXT、TEXT、MEDIUMTEXT、LONGTEXT，BLOB家族类似，只是存二进制。这些类型有一个共同限制：不能直接给默认值。所以如果业务需要字段有默认文本，优先用VARCHAR而不是TEXT；如果必须用TEXT，就只能通过应用层先INSERT再更新，或者用NULL配合空值判断。

3.3 排序规则 COLLATION，联表时最容易打架

同一个字段，如果两张表的排序规则不一致，JOIN或WHERE a.name = b.name时经常会报错：Illegal mix of collations。MySQL 8.0 默认的排序规则是utf8mb4_0900_ai_ci，它和老的utf8mb4_general_ci并不完全一样，所以不同版本迁移到一起时，很容易出现两边校验规则对不上。

解决方案是统一所有库和表的字符集与排序规则。如果你需要区分大小写，比如用户名登录，可以用utf8mb4_bin或utf8mb4_0900_as_cs。但要注意，排序规则不仅影响比较，还会影响UNIQUE约束和索引排序，比如大小写不敏感排序规则下，abc和ABC会认为重复而无法同时插入。

3.4 TEXT 不能全当垃圾桶

我看到很多项目喜欢把 JSON、XML、甚至一段很长的配置直接塞进TEXT。临时存可以，但如果你要频繁查询、过滤里面某个字段，那就非常痛苦。TEXT列无法直接加普通索引，必须指定前缀长度，比如KEY idx_text (content(100))，但前缀索引没法支持排序和精确覆盖查询。

更直接的办法是，JSON 就用JSON类型，结构化配置就拆成多个子字段。不要图一时省事，把大文本堆在一个字段里，等业务要求按内容过滤时再来后悔。

4. 日期与时间：你以为存的是绝对时间，其实可能是时区时间

4.1 五种时间类型，各自的使用场景

MySQL 8.0 提供DATE、TIME、DATETIME、TIMESTAMP、YEAR五种时间相关类型。这里面最常用的是DATETIME和TIMESTAMP，也是最容易混用的两个。

DATE存日期，比如生日、发版日期；TIME存时间段或时刻，比如每天开始营业的时间；YEAR存年份，只占 1 字节，范围 1901 到 2155。如果你的业务要精确到毫秒，可以在DATETIME或TIMESTAMP后面加精度，比如DATETIME(3)表示保留三位小数秒。

4.2 TIMESTAMP 和 DATETIME，区别不在存储范围

TIMESTAMP存储时会把当前会话时区的值转换成 UTC 再存，查询时又按会话时区转回来。也就是说，同一个时间值，在不同时区下显示会不一样。DATETIME完全不关心时区，你存进去什么样，查出来就是什么样。

这个差异在业务系统里非常现实。假设服务器时区从CST改成UTC，所有TIMESTAMP字段的显示全都变了，而DATETIME不变。所以我做业务表时会优先选DATETIME，尤其是订单时间、创建时间这些需要稳定展示的时间。如果是日志采集、监控打点、事件流水，用TIMESTAMP反而合适，因为系统各个组件通常都是 UTC 对齐。

4.3 默认值、自动更新和毫秒精度

MySQL 8.0 里DATETIME可以直接写DEFAULT CURRENT_TIMESTAMP(3)，也能配合ON UPDATE CURRENT_TIMESTAMP(3)实现每次更新记录时自动刷新updated_at。这是非常常见的时间戳方案，比在应用层手动取系统时间更省心。

从 8.0.13 开始，还支持表达式默认值，比如DEFAULT (NOW())可以写得更灵活。但要注意，表达式默认值不能牺牲可读性，该注释就注释，别让后来的同事看不懂。接 Java 时，记得 JDBC 连接参数里的serverTimezone要和数据库时区一致，否则本来存对了，读取时又被框架“好心”加偏移，最后出现经典的差 8 小时问题。

4.4 日期字符串永远不要用 VARCHAR 存

我见过不少表把日期字段设计成VARCHAR(20)，理由是方便展示。这个设计非常危险，因为字符串日期无法直接使用BETWEEN、DATE_ADD、DATE_FORMAT，也没法利用范围索引。MySQL 虽然能把'2025-01-01'隐式转成日期，但一旦格式带中文、带多种格式，排序和查询全部乱套。

日期字段就应该用日期类型，展示格式化放到应用层，或者使用 MySQL 的DATE_FORMAT函数。存成字符串等于把数据库最强大的时间函数全部废掉。

5. JSON、ENUM、SET 和空间类型，各有各的脾气

5.1 JSON 类型：8.0 的明星，但不是万能

MySQL 8.0 对 JSON 的支持已经很成熟。JSON列插入时会自动校验语法，底层使用二进制格式存储，并且支持->、->>、JSON_CONTAINS、JSON_TABLE等函数。相比直接塞TEXT，用JSON类型能避免“无效 JSON 也能入库”这种低级错误。

但 JSON 列也有明显短板：它不适合高频更新，因为修改其中一个键往往要把整个 JSON 文档重写；它不能直接建普通索引，只能通过生成列或函数索引来加速查询。比如要按tags里的status过滤，可以建一个生成列：

ALTER TABLE order_master ADD COLUMN tag_status VARCHAR(20) GENERATED ALWAYS AS (JSON_UNQUOTE(JSON_EXTRACT(tags, '$.status'))) STORED; ALTER TABLE order_master ADD INDEX idx_tag_status (tag_status);

如果你发现 JSON 里的字段频繁被拿来查询、统计，那说明这个数据其实应该拆成独立列，而不是长期留在 JSON 里。

5.2 ENUM 和 SET：看着省事，改起来费劲

ENUM能在数据库层限制字段的可选值，比如订单状态只能填created、paid、shipped。它存储很紧凑，只用 1 到 2 字节，查询时也能用字符串直接比较。坏处是，哪天你想加一个新的枚举值，必须执行ALTER TABLE修改字段定义，对于大表来说又是重量级操作。

更麻烦的是，ENUM的排序按照定义顺序，不是按字母顺序。比如定义('low','medium','high')，排序结果是low、medium、high，不是high、low、medium。如果你没意识到，很容易查出“莫名其妙”的顺序。

我的建议是：枚举值少且稳定时可以用ENUM或TINYINT加CHECK约束；枚举值可能扩展时，优先TINYINT加字典表。SET类型用于多个布尔标志的位组合，但查询和索引都不够友好，普通业务里不推荐。

5.3 空间类型，地图和地理业务的专属

空间类型包括GEOMETRY、POINT、LINESTRING、POLYGON这些，配合SRID来定义坐标系。MySQL 8.0 的 InnoDB 支持空间索引，可以做附近的人、区域查询这类 GIS 功能。不过普通互联网业务用到的不多，真要做地理计算，建议还是用专门的地图数据库，或者简单的经纬度拆分字段，不必一上来就上空间类型。

6. 一次建表实战：订单表的数据类型设计

6.1 先看一个可直接落地的建表语句

以常见的订单表为例，我按上面这些原则设计一份完整表结构：

CREATE TABLE `order_master` ( `id` bigint unsigned NOT NULL AUTO_INCREMENT COMMENT '订单ID', `order_no` varchar(64) NOT NULL COMMENT '业务订单号', `user_id` bigint unsigned NOT NULL COMMENT '用户ID', `total_amount` decimal(12,2) NOT NULL DEFAULT 0.00 COMMENT '订单总金额，单位元', `status` tinyint unsigned NOT NULL DEFAULT 0 COMMENT '订单状态 0-待支付 1-已支付 2-已发货 3-已完成 4-已取消', `remark` varchar(500) NOT NULL DEFAULT '' COMMENT '备注', `tags` json DEFAULT NULL COMMENT '拓展标签，如优惠券、渠道标识', `created_at` datetime(3) NOT NULL DEFAULT CURRENT_TIMESTAMP(3) COMMENT '创建时间', `updated_at` datetime(3) NOT NULL DEFAULT CURRENT_TIMESTAMP(3) ON UPDATE CURRENT_TIMESTAMP(3) COMMENT '更新时间', PRIMARY KEY (`id`), UNIQUE KEY `uk_order_no` (`order_no`), KEY `idx_user_id` (`user_id`), KEY `idx_status_created` (`status`, `created_at`), CONSTRAINT `chk_order_status` CHECK (`status` IN (0,1,2,3,4)) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci COMMENT='订单主表';

6.2 每个字段为什么要这么选

id用bigint unsigned，是因为订单量比用户量更容易上亿，INT很容易提前撑满。order_no是业务编号，有很强的字符串语义，可能包含前缀和日期，所以要VARCHAR(64)，并建唯一索引保证不重复。

user_id是用户表的主键，两边类型必须一致，都是bigint unsigned。这个点特别容易忽略，如果一边是INT，一边是bigint unsigned，JOIN时可能产生隐式转换，导致索引失效或者结果不符合预期。total_amount用decimal(12,2)，钱相关绝对不用浮点。status用tinyint unsigned并配合CHECK约束，等于在数据库层做了一层状态机校验，应用层写错了也会被拦下来。

创建时间用datetime(3)是因为业务展示需要一个固定不变的时间，不跟随会话时区变化；毫秒精度也足够。没有用TIMESTAMP的原因就是前面说的时区问题，线上服务器改时区不会影响已经写入的订单时间。

6.3 类型设计对索引的影响

idx_status_created这个复合索引，顺序是先status再created_at，因为最常见查询是“按状态过滤，再按时间倒序”。如果主查询是“查某个用户的订单并排序”，建议再加一个(user_id, created_at)的复合索引，单列idx_user_id能过滤用户，但排序还是要回到临时表。

字段长度也会影响索引体积。varchar(64)的订单号做唯一索引没问题，但如果某个字段实际只需要 32 位字符，却定义成varchar(255)，索引页能容纳的键值变少，B+ 树层级变高，查询效率会下降。类型设计与索引优化是强绑定的，这也是我建议建表时先想清楚每个字段真实最大长度的原因。

6.4 做 Migration 时，先检查类型定义

即使建表语句写得再规范，时间久了也会出现“某个字段从INT被改成BIGINT，另一个表没跟上”的情况。我每次做涉及表联合查询的迭代，都会先跑一下information_schema.COLUMNS，把所有关联字段的类型拿出来统一比对。也可以用这个 SQL 找到表里还残留的TEXT或异常默认值，避免上线后才发现两边对不上。

7. 常见问题与排查实录

7.1 排序规则不一致，联表直接报错

报错信息长这样：Illegal mix of collations (utf8mb4_general_ci,IMPLICIT) and (utf8mb4_0900_ai_ci,IMPLICIT) for operation '='。这种情况常见于你把 5.7 的表和 8.0 的表做JOIN，或者建库时字符集写得不统一。

排查时先看SHOW CREATE TABLE两张表，找到字段的字符集和排序规则，再统一改成一致。临时应急可以在查询后面加COLLATE utf8mb4_0900_ai_ci，但治本方案是把整库默认字符集和排序规则统一掉，否则每一条 SQL 都要挂COLLATE，又丑又容易漏。

7.2 隐式转换把索引搞没了

最常见写法是WHERE order_no = 10086，但order_no是varchar类型。MySQL 会把字符串列和数字比较时先转成数字，相当于对每个行执行了一次CAST(order_no AS SIGNED)，索引直接失效，表一大就全表扫描。

排查方法很简单，执行EXPLAIN看type是不是ALL，再用SHOW WARNINGS看优化器写的转换规则。修正方法是让查询参数类型和字段类型一致，比如WHERE order_no = '10086'。两个表关联时，字段类型不一致也会引发同样的隐式转换，尽量保证关联字段类型完全相同。

7.3 NULL、空字符串和 0 的选择

数据库里NULL和空字符串是两种完全不同的语义。NULL表示未知，不参与普通等于比较；空字符串表示存在但为空。业务上如果要求字段不能为空，直接建表时写NOT NULL DEFAULT ''，这样应用层拿到的永远是字符串，不用到处判断NULL。

但也要注意NULL在唯一索引里的特殊性：一个唯一索引可以包含多个NULL，因为NULL不参与唯一性比较。如果你想把某一列做强唯一，比如业务单号不允许重复，那字段就应该NOT NULL并建唯一索引，而不是允许NULL。

7.4 FLOAT 金额差几分，DECIMAL 也会溢出

金额场景用FLOAT是典型的低级错误，这个我前面反复提过。改用DECIMAL之后，新的问题可能是聚合溢出。比如total_amount DECIMAL(10,2)，但SUM(total_amount)的结果精度可能会扩大到DECIMAL(13,2)左右，如果total_amount定义了偏小，SUM结果反而会out of range，应用层读出来就开始报错。

稳妥做法是在 SQL 里显式CAST(SUM(total_amount) AS DECIMAL(14,2))，或者在应用层用高精度类型接收，再慢慢处理。总之，DECIMAL的精度要按未来的聚合结果预估，而不是按单条记录的大小预估。

7.5 “差八小时”问题到底怎么排查

线上时间差 8 小时，通常发生在TIMESTAMP列和 JDBC 时区配置不一致的时候。先按顺序查三样东西：

• SELECT @@global.time_zone, @@session.time_zone;看数据库时区；
• 看 JDBC URL 里的serverTimezone=Asia/Shanghai或serverTimezone=UTC；
• 看执行连接的服务器本地时区。

如果库表用的是TIMESTAMP，写入和读取都会按会话时区转换，应用框架和数据库时区不一致，就会出现“存进去是对的，查出来偏了 8 小时”的诡异情况。如果换用DATETIME，这个问题会好很多，但应用层还是要约定好统一时区，否则传给前端的时间字符串还是可能错。

7.6 JSON 查询时的引号陷阱

用 JSON 类型时，tags->'$.name'返回的是带引号的 JSON 字符串，比如"zhangsan"，而tags->>'$.name'返回不带引号的纯文本zhangsan。如果你在日志里看到数据外面多了一对双引号，多半是->和->>用混了。

这个问题不是 SQL 语法错误，而是结果类型语义不同，容易在应用层被当成脏数据。建议团队里约定：查询 JSON 字段统一用->>，除非你明确需要 JSON 格式结果。另一个高频坑是直接在代码里手拼 JSON 字符串，少转义一个引号，数据库就拒绝插入，直接报Invalid JSON text。正确做法是用序列化库生成 JSON，而不是字符串拼接。

8. 一些长期有用的设计习惯

8.1 每个字段都写一个“为什么”

建表语句里不要只写类型和长度，还要把业务含义和取值范围注释清楚，尤其是枚举字段。比如status tinyint unsigned NOT NULL DEFAULT 0 COMMENT '订单状态 0-待支付 1-已支付...'。这样后来接手的人不用去翻需求文档，光看表结构就能知道每个数字代表什么。

我自己的习惯是建表后跑一次SHOW CREATE TABLE，把所有字段再读一遍，确认类型、默认值、注释都符合预期。这比写完直接上线要安心得多。

8.2 把类型设计放进 Code Review

很多人做表结构评审时只会看 SQL 语法对不对，不会去问“这个字段最大是多少、有没有小数、要不要参与计算”。我建议把这些追问变成固定动作：先确认数据语义，再看类型精度，最后看索引能不能支撑查询。只要这三关都过了，类型设计基本不会出大问题。

比如 IP 地址，INET_ATON转成INT UNSIGNED存储很省空间，但如果业务里经常要直接展示 IP 或者做字符串模糊匹配，存VARCHAR(45)反而更直观。类型没有绝对最优，只有适不适合当前业务。

8.3 最后分享一个常用技巧

当你拿不准某个字段该选什么类型时，可以先看information_schema.COLUMNS里现有表是怎么设计的，或者查官方文档关于允许范围的描述。8.0 的EXPLAIN和SHOW WARNINGS也能帮你发现隐式转换问题。类型设计这件事，前期多花十分钟，后期就能少熬几个晚上的排障班。我个人现在越来越喜欢在建表时留一点点冗余，比如主键用BIGINT、金额用DECIMAL(14,2)，因为业务增长速度往往比想象得快，与其冒风险，不如一开始就选一个更稳的类型。