MySQL 8.0 的基本数据类型听起来只是建表时随手填的一个类型实际上却决定了查询能不能走索引、数据准不准、后期改表要熬几个夜。我见过不少项目一开始不重视类型等到表里有几千万行时想把INT改成BIGINT、把VARCHAR改成TEXT才发现一次ALTER TABLE能把整张表锁到业务超时。这篇内容我按 MySQL 8.0 的实际情况把基本数据类型完整拆一遍覆盖整数、小数、字符串、日期时间、JSON、ENUM/SET以及建表和排障过程中的坑适合正在学 MySQL 的新手也适合正在做数据库建模和版本迁移的开发者。1. 动手建表前先把类型这件事想清楚1.1 类型选错的代价从来不是事后改一行 DDLMySQL 8.0 虽然对 DDL 做了不少优化比如ALGORITHMINSTANT可以快速增加列但当你需要修改已有列的类型时大部分情况下还是要把表复制一遍或者重建索引。几百万行的表可能还能忍几千万行的主表一旦触发全表重建主从延迟、磁盘 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 里整数类型有五种差别主要在字节数和取值范围直接看表最直观类型字节有符号范围无符号范围常见场景TINYINT1-128 ~ 1270 ~ 255状态码、开关标识SMALLINT2-32768 ~ 327670 ~ 65535小规模计数器MEDIUMINT3-8388608 ~ 83886070 ~ 16777215中等数字比如访问量INT4-2147483648 ~ 21474836470 ~ 4294967295常规主键、编号BIGINT8很大很大大表主键、雪花 ID、金额的分很多人喜欢“保守”地用INT当主键但现在的订单量、用户量涨起来非常快一旦INT自增超过 21 亿主键直接满。如果是新表主键我推荐直接BIGINT UNSIGNED别等以后再来一次痛不欲生的主键类型迁移。对于状态位这种字段TINYINT就够了。比如订单状态用 0 到 5 表示完全不需要INT更不需要VARCHAR。INT占 4 字节是TINYINT的四倍一个表里如果到处都是INTInnoDB 的聚簇索引会膨胀很多。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的精度上限是M65D30如果业务需要超过这个精度就别硬塞给数据库字段考虑换存储方案。另外两个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、LONGTEXTBLOB家族类似只是存二进制。这些类型有一个共同限制不能直接给默认值。所以如果业务需要字段有默认文本优先用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)) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COLLATEutf8mb4_0900_ai_ci COMMENT订单主表;6.2 每个字段为什么要这么选id用bigint unsigned是因为订单量比用户量更容易上亿INT很容易提前撑满。order_no是业务编号有很强的字符串语义可能包含前缀和日期所以要VARCHAR(64)并建唯一索引保证不重复。user_id是用户表的主键两边类型必须一致都是bigint unsigned。这个点特别容易忽略如果一边是INT一边是bigint unsignedJOIN时可能产生隐式转换导致索引失效或者结果不符合预期。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 里的serverTimezoneAsia/Shanghai或serverTimezoneUTC看执行连接的服务器本地时区。如果库表用的是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)因为业务增长速度往往比想象得快与其冒风险不如一开始就选一个更稳的类型。