MySQL数据类型选型：从int(5)到DATETIME，避开设计与性能的坑

你在搜索引擎里输入“MySQL 常见数据类型”，大概率是遇到了两类问题：一类是建表时拿不准某个字段到底该用 INT 还是 BIGINT、VARCHAR 还是 TEXT、DATETIME 还是 TIMESTAMP；另一类是面试时被 int(5) 这种看起来像“长度”的参数问住了。今天把这两类问题一起讲透。数据类型选型这件事，表面上看只是“写几个单词”，但它决定了存储空间的占用、索引的生效方式、查询是否会被隐式转换破坏，甚至会决定你的系统在 2038 年还能不能正常跑。下面直接进入正题，先从最容易误导人的 int(5) 说起。

1. 先把 int(5) 的“5”搞明白：数值类型到底要怎么选

1.1 显示宽度：一个影响了无数新人的历史包袱

网上关于 MySQL 数据类型的搜索里，“mysql中int+5”长期占据热搜，说明这个点坑了不止一代人。很多人建表时写过这样的语句：

sql复制CREATE TABLE t_demo (
    id INT(5) NOT NULL AUTO_INCREMENT,
    age INT(4) DEFAULT NULL,
    PRIMARY KEY (id)
);

然后理所当然地以为：INT(5) 表示这个字段最多只能存 5 位数字，INT(4) 最多只能存 4 位。这是错误的。INT 类型的存储范围由 INT 本身的 4 个字节决定：有符号时是 -2147483648 ~ 2147483647，无符号时是 0 ~ 4294967295。你把 INT(5) 建出来，插入 999999999 完全没问题，MySQL 不会因此报错，也不会截断。

那括号里的 5 到底是什么意思？它叫“显示宽度”（display width）。在早期 MySQL 版本里，如果你配合 ZEROFILL 属性使用，INT(5) 在显示时会把不足 5 位的数字前面补 0。例如 INT(5) ZEROFILL 插入 1，查询出来显示为 00001。如果不加 ZEROFILL，这个宽度几乎没有实际作用，只是一种“显示上的提示”，不影响存储，也不影响计算。

MySQL 8.0.17 开始，整数类型的显示宽度已经被标记为废弃，不再产生任何实际效果。也就是说，新版 MySQL 里你写不写 INT(5) 都一样，官方都懒得支持了。所以别再去背“int(5)代表5位数”这种错误说法了。

1.2 整数各档位的存储字节和范围怎么记

MySQL 常见整数类型有 TINYINT、SMALLINT、MEDIUMINT、INT、BIGINT，它们的核心差异就是存储字节数和范围。为了方便记忆，我一般用一张表总结：

选型建议很直接：能确定取值范围时，选最小的够用类型。比如用户状态只有 0、1、2、3，你用 TINYINT 就够了，没必要 INT。状态字段如果搞成 INT，不仅浪费存储，还会让索引页能容纳的行数变少，查询时扫描的页更多。

同时要注意 UNSIGNED 的使用。如果字段语义上不会出现负数，比如年龄、计数、自增主键，可以考虑无符号，这样正数范围翻倍。但有一点要特别提醒：MySQL 中两个 UNSIGNED 整数做减法时，如果结果是负数，会产生 BIGINT UNSIGNED value is out of range 的报错。比如 UPDATE t SET count = count - 1 WHERE id = 1，当 count 已经为 0 时，这个 SQL 在严格模式下会直接报错。所以不是所有场景都适合加无符号，要看业务逻辑里有没有可能让数值变成负数。

1.3 金额、主键和自增：DECIMAL 与 BIGINT 的高频场景

数值类型里还有两个高频选择：DECIMAL 和浮点类型 FLOAT、DOUBLE。很多人一开始都用 DOUBLE 存金额，后来在账单对不上时才醒悟。原因是 FLOAT 和 DOUBLE 是浮点数，底层用二进制近似表示，无法精确表达很多十进制小数。经典的例子是 0.1 + 0.2 在浮点数体系里不等于 0.3，会产生一个很长的尾数。这在工程计算里可能能接受，但金额差一分钱就是事故。

DECIMAL 是定点数，用来精确表示十进制小数。定义格式是 DECIMAL(M, D)，其中 M 是总位数，D 是小数位数。例如 DECIMAL(10, 2) 表示总共 10 位，其中小数 2 位，整数部分最多 8 位，能存的最大值是 99999999.99。设置小数位时要注意，如果插入的数据小数位超过 D，严格模式下会报错或四舍五入，非严格模式下可能被截断。所以一张订单表如果要存金额，建议直接 DECIMAL(12, 2)，整数部分 10 位足够绝大多数国内电商场景。

自增主键也是数值类型里的经典问题。很多老项目里主键用 INT，一旦数据量超过 21 亿，INT 就到顶了。因此在新建表时，我习惯直接给主键用 BIGINT UNSIGNED，不要等到线上报 Out of range value 再来改表——改主键类型是个非常重的大动作，锁表时间长，风险高。同样，分布式场景里的雪花 ID 是一个 64 位整数，如果主键设计成 INT，插入时马上就会溢出。这里需要一个新人容易忽视的点：如果你在 Java 里定义的实体主键是 Long，数据库主键却建成了 INT，等数据量上来之后，前端的 Long 精度也可能在序列化时丢失。这是数据建模层面的问题，建表前就要想好。

2. CHAR 和 VARCHAR 的差别，不只是定长和变长

2.1 括号里的 N 是字符数，不是字节数

CHAR(N) 和 VARCHAR(N) 里的 N 是字符数，不是字节数。这一点特别容易被误解。比如 VARCHAR(20)，在 utf8mb4 字符集下，最多能存 20 个汉字，也能存 20 个英文字母。至于占多少字节，要看具体字符：英文字母在 utf8mb4 下通常 1 字节，大部分汉字 3 字节，某些生僻字和 emoji 表情是 4 字节。也就是说，“VARCHAR(255) 最多能存 255 个字符”，跟“最多 255 个字节”完全是两回事。

正因为 VARCHAR 的字节数会随字符集变化，所以选长度时要考虑到最坏情况。如果一列允许用户输入 emoji，每个字符按 4 字节算，那么 VARCHAR(255) 在最坏情况下可能占 1020 字节，这会直接影响到 InnoDB 的索引键长度和行大小限制。MySQL 5.7 之前，InnoDB 索引键最长 767 字节，utf8mb4 下的 VARCHAR(255) 很容易超过限制，因此当时网上广泛流传“utf8mb4 下 VARCHAR(191) 最安全”。MySQL 5.7.7 之后默认开启了 innodb_large_prefix，使用 DYNAMIC 行格式时索引键上限扩展到 3072 字节，8.0 里 VARCHAR(255) 建索引已经不太会碰到旧版限制。但是，不要因为这就不管长度，字段长度越大，内存排序、临时表消耗都更大，无脑放大只会换来以后无法挽回的粗糙设计。

2.2 CHAR 的尾部空格问题

CHAR(N) 是定长字符串，最大长度 255 字符。它的存储方式是：如果存入的内容不足 N 个字符，右侧用空格补齐到 N 个字符再存储。取出时，MySQL 默认会去掉尾部空格。这带来一个很实际的坑：如果你想在 CHAR 字段里保存一个有业务意义的尾部空格，比如 "abc "，查询出来会变成 "abc"，数据语义被悄悄改变了。

VARCHAR(N) 是变长字符串，只存储实际内容加 1~2 字节的长度前缀，所以尾部空格会保留。但在比较时，很多排序规则（collation）默认不区分尾部空格，WHERE name = 'abc' 也可能匹配到 name = 'abc ' 的记录。这个行为在 MySQL 8.0 中取决于排序规则的 PAD SPACE 属性，默认的 utf8mb4_0900_ai_ci 就属于 PAD SPACE，它比较字符串时会忽略尾随空格。如果业务上对空格敏感，要使用 BINARY 或 utf8mb4_bin 排序规则，或者自己在应用层处理好数据。

什么时候用 CHAR？一个典型场景是存储固定长度的编号，比如身份证号、银行卡号、固定长度订单号。用 CHAR 的好处是存储结构紧凑，每行长度固定，行迁移概率低。但现实中很多“看似固定”的编号会随着业务变化而变长，比如手机号在不同国家长度不同，所以不要因为“现在的号码是11位”就设计成 CHAR(11)，要考虑国际化和未来扩展。用 VARCHAR(20) 存手机号反而更稳妥。

2.3 VARCHAR 长度选多少？不要无脑 255

我见过大量建表语句把 VARCHAR 一律写成 255，理由是“反正长度不够可以扩”。这种偷懒会带来几个后续问题：

• 如果业务内容只需要 20 个字符，存成 255 会让 InnoDB 在内存中处理每行时预留更大空间，排序、JOIN 时临时表可能更大；
• 使用前缀索引或者联合索引时，字段过长容易逼近索引键长度限制；
• ORM 框架常常根据字段长度做参数校验，255 会让接口层失去第一道防线；
• 最重要的是一旦这个字段要参与 ALTER TABLE 重建或大范围更新，长字段修改成本也会更高。

更合理的做法是：根据业务能接受的最大值来估算。比如用户昵称，一般限制 20 个字符已经足够，底层给 VARCHAR(50) 留足余量；商品标题可能需要 100 个字符以内，给 VARCHAR(200) 也合理；备注类文本可能更长，但也不至于一上来就 TEXT。长度选型没有绝对公式，核心原则是“够用 + 合理余量 + 不过度放大”。

真正超过一定长度后，比如内容可能有几万字符，VARCHAR 也能存，但 MySQL 单行有大约 65535 字节的限制，单列 VARCHAR 太长会把行大小顶爆。InnoDB 对大字段有溢出页机制，TEXT、大 VARCHAR 超出部分会存到额外页，读取时会有额外 IO。所以处理超长文本时，如果业务确实需要，可以分几种思路：正文类内容放对象存储，数据库只存地址；必须入库的，用 TEXT；如果内容是中等的几千字符，VARCHAR(2000) 也是可以的，但要知道它已经可能触发行大小限制，具体需要结合整行的其他字段统一评估。

3. 时间字段的选择，决定了你的系统过不过得了 2038 年

3.1 DATETIME 与 TIMESTAMP 的核心分歧

时间字段是数据建模里最容易被低估的部分。DATETIME 和 TIMESTAMP 是两种最常用的类型，但它们的差别很大。

TIMESTAMP 只有 4 字节，所以能表示的时间范围非常有限，最远到 2038 年。这个“2038 年问题”对很多系统来说是真实存在的：如果表里有一个 TIMESTAMP 类型的字段，而你的业务需要记录 2038 年 1 月 19 日之后的事件，这个字段就会溢出。有人会说“我的系统活不到 2038 年”，但想想银行存单、保险合同、长期会员，很多业务是有 20 年以上生命周期的。

TIMESTAMP 还有一个特性是依赖时区。如果你的应用有多个时区的用户，TIMESTAMP 在写入时会按当前会话时区转成 UTC，查询时会再转回来，这看起来方便，却也容易造成团队协作中的混乱。比如一个横跨中美两个时区的团队，A 地插入一条记录，B 地查询时看到的时间会自动变成 B 地时区的时间。如果你不想要这种“自动换算”，或者应用层已经统一使用 UTC 时间，用 DATETIME 更可控。它不关心时区，存什么就是什么。

我的习惯是：凡是新项目，时间字段默认用 DATETIME，应用层统一按 UTC 存储和传输，展示时再转本地时区。这样可以完全绕开 TIMESTAMP 的 2038 限制和时区隐式转换问题。当然，如果你确实想利用数据库层自动做时区转换，且确定业务不会超过 2038 年，TIMESTAMP 也不是不能选，但团队内部要对“统一时区”达成强烈共识，否则排查问题时会非常痛苦。

3.2 毫秒精度、默认值和自动更新时间

很多业务并不只需要精确到秒。订单创建时间、日志时间、并发场景下的更新时间，都建议精确到毫秒甚至微秒。MySQL 对日期时间类型支持精度参数：DATETIME(3) 表示毫秒，DATETIME(6) 表示微秒。TIMESTAMP 同理。

为了省事，可以在建表时直接把创建时间和更新时间交给数据库管理：

sql复制CREATE TABLE t_order (
    id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT,
    created_time DATETIME(3) NOT NULL DEFAULT CURRENT_TIMESTAMP(3),
    updated_time DATETIME(3) NOT NULL DEFAULT CURRENT_TIMESTAMP(3) ON UPDATE CURRENT_TIMESTAMP(3),
    PRIMARY KEY (id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

DEFAULT CURRENT_TIMESTAMP(3) 表示插入时自动填当前时间；ON UPDATE CURRENT_TIMESTAMP(3) 表示行内任意字段被更新时，这个字段自动变成更新时间。这样应用层就不用每次手动维护 updated_time，也能避免多个服务实例本地时钟不一致导致的时间错乱。注意，这里的更新时间是数据库服务器时间，如果数据库和应用服务器时钟不一致，时间可能会有偏差。

精度参数是有代价的：小数秒的存储需要额外字节，例如 DATETIME(3) 要在 8 字节基础上再增加 1~2 字节。这个代价通常可以接受，但没必要每一个时间字段都上精度 6。如果业务只需要到秒，写 DATETIME 就够，别为了“精确”白白增加存储。

3.3 不要用字符串或拆开的年月列来存时间

有些从业者习惯用 VARCHAR 存日期，或者把年份和月份拆成 year、month 两列单独存。这类设计的查询体验非常差：

• 用字符串存 2025-06-01 12:30:00，虽然看起来直观，但 BETWEEN、区间比较、按月分组都需要隐式转成日期，或者截取字符串，很容易索引失效；
• 把年月拆列，统计“今年 3 月到 6 月的数据”时，条件写得又长又容易错：

  sql复制WHERE year >= 2025 AND (year > 2025 OR month >= 3)
  

  这种条件不仅没法走联合索引，写错边界也是常事；
• 如果只关心日期、不关心时间，直接使用 DATE 类型，3 字节存储，干净利落。如果关心时分秒，使用 DATETIME 或 TIMESTAMP。数据库自带的时间函数、索引优化、分区裁剪，都是为这些原生类型设计的，直接用它们的效率最高。

还有一点：字段默认值不要允许“零日期”，比如 0000-00-00。在严格 SQL 模式下，写入零日期会直接报错；即使能写入，很多 ORM 和驱动在读取时也可能解析失败，造成应用层崩溃。建表时给时间字段一个合理默认值，比如 CURRENT_TIMESTAMP，而不是让它可以为空或为零值，能帮你挡掉很多运行时异常。

4. JSON、ENUM、BIT 这些“特殊类型”：平时不见，一用就踩坑

4.1 JSON 好用，但别把关系型数据库当成文档库

MySQL 5.7 开始提供了原生 JSON 类型，8.0 对 JSON 的支持进一步增强。它和 VARCHAR 存一段 JSON 字符串最大的区别在于：数据库会校验 JSON 格式合法性，并且你可以用 JSON 表达式去查询内部字段。

sql复制CREATE TABLE t_product (
    id BIGINT NOT NULL AUTO_INCREMENT,
    name VARCHAR(100) NOT NULL,
    attr JSON,
    PRIMARY KEY (id)
);

INSERT INTO t_product (name, attr) VALUES ('T恤', '{"color": "red", "size": "L"}');

查询 JSON 内部字段有两种常见写法：

sql复制SELECT attr->'$.color' FROM t_product WHERE id = 1;      -- 返回 "red"（带引号）
SELECT attr->>'$.color' FROM t_product WHERE id = 1;     -- 返回 red（纯字符串）

在 WHERE 条件里也可以用 attr->>'$.size' = 'L' 这种写法。但是这里有一个非常重要的坑：JSON 内部字段默认不能走普通索引。如果你频繁按 attr->>'$.size' 查询，数据量大了之后性能会直线下降。解决办法是建生成列，把需要过滤的 JSON 字段提取出来并加索引：

sql复制ALTER TABLE t_product
    ADD COLUMN attr_size VARCHAR(10)
    GENERATED ALWAYS AS (attr->>'$.size') STORED,
    ADD INDEX idx_attr_size (attr_size);

那是不是可以把经常变化、结构不稳定的业务属性都塞进一个 JSON 字段里？我的看法是：JSON 适合“低频查询、结构多变、字段大多只做展示”的场景。如果这些属性将来要频繁参与统计、排序、关联，那它本就不该塞进 JSON，而应该拆成独立字段或子表。另一个隐藏问题：更新 JSON 字段时，MySQL 会重写整个 JSON 文档，而不是只更新其中一个 key。所以如果你有一个高频更新 JSON 内部某个计数器的场景，建议把计数器拆成独立整数列，否则写入压力和锁竞争都会放大。

4.2 ENUM 的排序陷阱和“加值成本”

ENUM 在有些教材里是“字符串类型的优化版本”，因为它内部按整数存储，能让数据更紧凑。但真实业务里，它带来的坑往往比收益更大。

第一个坑在排序。ENUM 的顺序不是按字符串字典序，而是按枚举定义的先后顺序。比如：

sql复制CREATE TABLE t_order_status (
    status ENUM('pending', 'paid', 'shipped', 'cancelled')
);

这时执行 ORDER BY status，结果会按 pending < paid < shipped < cancelled 的顺序排，因为它们内部存储值分别是 1、2、3、4。如果业务期望按生命周期排，可能正好符合；如果只是想要字典序，这个结果会显得很意外。

第二个坑是加新值成本。ENUM 要新增一个枚举值时，比如加一个 refunded，需要执行 ALTER TABLE 修改列定义。虽然 MySQL 8.0 对在末尾添加枚举值使用了更轻量的 INSTANT 算法，但在中间插入、删除或重排枚举值，可能触发表重建，代价不小。更麻烦的是，如果应用代码已经按位置把枚举值映射成了 int，重建后顺序一变，数据含义就全乱了。

第三个坑是脏数据处理。非严格模式下，往 ENUM 列插入一个不在定义范围内的值时，MySQL 不会报错，而是插入一个空字符串 ''，很多人排查问题时根本想不到这个来源。

如果你确实需要一个状态字段，我建议用 TINYINT 加注释或代码层字典表。TINYINT 加新状态不需要改表结构，排序语义由程序控制，数据导出也不会因为看到 1 却不知道含义而一头雾水。当然，如果团队规范明确、ENUM 可选值极少且永不需要增删，用它也不是不行，只是我很少在需要长期维护的业务表里主动推荐它。

4.3 BIT 表示布尔值，会让很多驱动很难受

BIT 类型用来按位存储，比如 BIT(8) 可以存一个 8 位二进制数，适合表示一组开关位。但有个高频误用：用 BIT(1) 表示布尔值，比如 is_deleted BIT(1)。

这个设计在数据库层面没问题，但在实际项目里会遇到一个很具体的问题：很多语言驱动读取 BIT(1) 时，拿到的并不是一个干净的 true/false，而是一个字节数组。在 Java 的 JDBC 里，ResultSet.getObject() 返回的是 byte[]，导出的数据也可能显示成一串不可读字符。相比之下，用 TINYINT(1) 加上注释约定 0 表示否、1 表示是，几乎对所有驱动都友好，也便于运维时直接看数据理解含义。所以，除非你是真的在做位图、权限位、开关组合这类需要按位运算的场景，否则业务表的布尔字段就用 TINYINT(1)。

5. 用一张真实订单表，把字段类型选型的逻辑串一遍

5.1 建表 SQL 演示

前面讲了很多原则，这里写一个综合示例，把常见的选型思路应用进去。

sql复制CREATE TABLE `user_order` (
    `id` BIGINT UNSIGNED NOT NULL AUTO_INCREMENT COMMENT '主键ID',
    `order_sn` VARCHAR(32) NOT NULL COMMENT '业务订单号',
    `user_id` BIGINT UNSIGNED NOT NULL COMMENT '用户ID',
    `order_type` TINYINT NOT NULL DEFAULT 0 COMMENT '订单类型：0-实物 1-虚拟',
    `total_amount` DECIMAL(12,2) NOT NULL DEFAULT 0.00 COMMENT '订单总金额',
    `pay_amount` DECIMAL(12,2) NOT NULL DEFAULT 0.00 COMMENT '实付金额',
    `discount_amount` DECIMAL(12,2) NOT NULL DEFAULT 0.00 COMMENT '优惠金额',
    `status` TINYINT NOT NULL DEFAULT 0 COMMENT '状态：0-待支付 1-已支付 2-已发货 3-已完成 4-已取消',
    `receiver_name` VARCHAR(50) NOT NULL DEFAULT '' COMMENT '收货人姓名',
    `receiver_mobile` VARCHAR(20) NOT NULL DEFAULT '' COMMENT '收货人手机号',
    `remark` VARCHAR(500) NOT NULL DEFAULT '' COMMENT '用户备注',
    `created_time` DATETIME(3) NOT NULL DEFAULT CURRENT_TIMESTAMP(3) COMMENT '下单时间',
    `paid_time` DATETIME(3) DEFAULT NULL COMMENT '支付时间',
    `updated_time` DATETIME(3) NOT NULL DEFAULT CURRENT_TIMESTAMP(3) ON UPDATE CURRENT_TIMESTAMP(3) COMMENT '最后更新时间',
    PRIMARY KEY (`id`),
    UNIQUE KEY `uk_order_sn` (`order_sn`),
    KEY `idx_user_id_created` (`user_id`, `created_time`),
    KEY `idx_status_created` (`status`, `created_time`),
    KEY `idx_paid_time` (`paid_time`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci COMMENT='用户订单表';

下面解释几个关键选择：

• id 用 BIGINT UNSIGNED。订单表是长期运行的核心表，自增主键按 INT 到 21 亿很容易触顶，直接给 64 位空间更安心。
• order_sn 用 VARCHAR(32) 而不是 BIGINT。订单号虽然经常是数字，但它本质是一个业务标识，不是用来做算术的；用 VARCHAR 可以容纳将来可能出现的字母、后缀、日期段，也避免超出 BIGINT 范围的隐患。同时加上唯一索引，防止重复下单。
• user_id 是外键指向用户表，用与用户表完全一致的类型 BIGINT UNSIGNED。JOIN 时如果两边类型不一致，MySQL 可能做隐式转换，导致索引失效，这是常见性能隐患。
• total_amount、pay_amount 用 DECIMAL(12,2)。如果要支持更大金额，可扩到 DECIMAL(14,2)，但绝不用浮点类型。
• order_type 和 status 用 TINYINT，不用 ENUM，不用 VARCHAR。状态字段通常会被频繁用于过滤和统计，TINYINT 对索引友好，扩展状态不需要改表。每个取值都在字段注释里写明含义，避免团队内理解不一致。
• receiver_mobile 用 VARCHAR(20) 而不是 BIGINT。手机号本质是字符串，BIGINT 会丢掉前导零，也容易因为超过整数范围而出错；VARCHAR(20) 足够容纳全球主流号码。
• remark 用 VARCHAR(500)，不直接上 TEXT。500 字符对一般备注完全够用，而 TEXT 在排序和临时表处理上代价更高。如果后续真有超长内容，再单独拆出“订单日志表”。
• created_time、updated_time 用 DATETIME(3)，配合默认值和自动更新，让数据库统一维护时间。paid_time 允许为 NULL，因为只有支付完成后才有值，NULL 在这里语义合理。其余绝大多数字段都用 NOT NULL 加默认值，避免数据里出现大量未知空值。

5.2 建表后的类型自查习惯

我每次写完表结构，会习惯性地做一遍十分钟检查，重点看下面几条：

1. 所有字段类型是不是“能达到业务目的的最小可用类型”。状态用 TINYINT 就够的，绝不写 INT；能用 DATE 的就不用 DATETIME。
2. 是否所有布尔字段都用 TINYINT(1)，有没有误用 BIT。
3. 金额相关字段是不是全部使用了 DECIMAL，小数位是否统一。
4. 字符集是否统一为 utf8mb4，有没有字段因为大小写敏感需求而专门设置 utf8mb4_bin。
5. 每个时间字段是否都明确了精度：到秒还是到毫秒，有没有遗漏的 DEFAULT CURRENT_TIMESTAMP。
6. 作为外键或 JOIN 条件的列，类型是否与关联表完全一致。
7. 所有字符串类型字段是否都加上了注释，状态值是否在注释里有对应关系说明。
8. 有没有无意中使用 NULL 来让业务表达“暂时无值”，如果有，这个列是否真的必须允许为空。
9. 查询和排序频繁的字段是否能从普通字段类型匹配到合适的索引。比如 WHERE status = 1 ORDER BY created_time DESC，我会设计联合索引 (status, created_time)，而不是让排序单独吃一个文件排序。
10. 有没有哪个字段是临时拍的脑袋。比如状态字段用 ENUM、手机号用 BIGINT、金额用 DOUBLE，只要有任何一个，立刻回炉重改。

这些检查不需要很复杂，但它能逼着你在建表阶段就把问题想清楚。真等数据上了百万行再改类型，无论是 ALTER TABLE 重建还是应用层兼容，都会非常疼。

5.3 怀疑字段类型不对时，怎么快速查清

实际维护过程中，你可能会拿到一个别人建的表，看不出某个字段的定义。这时用三个 SQL 就能快速确认：

sql复制SHOW CREATE TABLE user_order\G

SHOW CREATE TABLE 会输出完整的建表语句，最直观地展示每个字段的类型、默认值、注释和索引。

sql复制DESC user_order;

DESC 输出字段名、类型、是否允许为 NULL、键信息、默认值等。

如果你需要批量查库里的字段类型，可以直接查 information_schema.COLUMNS：

sql复制SELECT
    COLUMN_NAME,
    COLUMN_TYPE,
    IS_NULLABLE,
    COLUMN_DEFAULT,
    CHARACTER_SET_NAME,
    COLLATION_NAME
FROM information_schema.COLUMNS
WHERE TABLE_SCHEMA = 'your_database'
  AND TABLE_NAME = 'user_order';

查出来之后，如果确认类型不合理，再考虑 ALTER TABLE ... MODIFY COLUMN。修改字段类型前务必先看当前表的行数、磁盘大小、是否有长期事务阻塞。DDL 在 MySQL 8.0 中很多操作已经支持 ALGORITHM=INPLACE，但依然会带来主从延迟和元数据锁风险，适合在业务低峰期执行，并先在测试库跑一遍。

我自己的习惯是，收到任何“某段时间查询突然变慢”的反馈时，第一件事先看关联条件两侧字段类型是否一致，然后在 EXPLAIN 输出里找有没有 Using filesort 或者 type = ALL。很多时候根因就是字段类型匹配不当，改一个列的类型，比加十个索引更管用。

最后再分享一个个人习惯：表结构定稿前，我会把每一列的字段类型和设计理由对着旁边同事讲一遍。不要觉得这很麻烦，讲的过程里最容易暴露出自己都没想清楚的类型选择，例如“为什么这个状态不用 TINYINT 要用 VARCHAR”“为什么这个时间不用 TIMESTAMP”。如果能用三句话解释清楚每一个字段的类型为什么是这样，这张表的数据类型设计基本上就稳了。