聊到MySQL，数据类型可能是最容易被忽略却又最值得较真的一块。很多人建表时习惯性用int+varchar(255)一把梭，直到线上出现慢查询、磁盘占用异常、数据被隐式转换吃掉精度，才会回头审视当初的表结构。我做过不少MySQL运维和性能排查，几乎每个典型案例挖到最底层，都能看到数据类型设计埋下的隐患。这篇文章写给正在学MySQL的初学者，也给那些已经在写业务代码、但没时间系统梳理数据类型的开发者，把“选型应该怎么想”和“底层到底发生了什么”讲清楚。
1. 为什么要较真数据类型：几个真实翻车现场
1.1 用错类型导致的存储与性能问题
我记得有一次帮客户排查一个订单表，才几百万行数据，单表却占了将近20GB，查询速度还慢得离谱。打开表结构一看，订单状态字段用的是varchar(50)，存的内容无非就是“待支付”“已支付”“已发货”这几个中文词。更离谱的是，金额字段用的是double，连小数精度都保证不了。这种设计带来的问题很直接：索引长度被撑大，内存和磁盘的浪费成倍增加，而且查询时因为字符集转换、排序规则复杂，性能也变差。
很多人不理解，为什么数据类型会影响性能。你可以把InnoDB的表想象成一个书架，字段类型就是每一格预留的空间。varchar(255)意味着每一行都可能给你预留640个字节的容量上限（按utf8mb4计算），哪怕你只存了一个字，索引和排序依然要考虑这个上限。而如果你用tinyint，整个字段只需要1个字节。同样一页16KB的数据页，能存下的行数天差地别。行数越多，扫描开销、内存占用、缓存命中率都会跟着变差。
1.2 隐式转换和排序规则的坑
还有一个典型的翻车现场是隐式类型转换。比如用户表里mobile字段是varchar类型，你查询时忘了加引号，写了WHERE mobile = 13800138000，MySQL会自动把字符串转换成数字去比较。一旦发生隐式转换，索引基本就废了，因为优化器无法对mobile列直接使用索引，只能全表扫描。问题不出在业务逻辑，而是类型不匹配。
排序规则（collation）也会因为类型选择出问题。如果字符串字段用了错误的字符集和排序规则，中文排序、大小写判断都可能不符合预期。比如很多业务要求“不区分大小写”的用户名，结果字段用的utf8mb4_bin，导致Admin和admin被当成两个用户，注册时查重竟然通过了。这些坑都不是SQL写错，而是建表时对数据类型和附属属性考虑不够。
1.3 数据类型影响SQL优化器判断
优化器能不能走索引、走什么索引，很大程度上取决于字段类型。整数的比较成本最低，短字符串次之，长字符串和TEXT最麻烦。如果你在一个varchar(1000)的字段上建索引，InnoDB默认会限制索引长度，可能只能对前缀建索引，查询范围稍微一变，索引就失效。更麻烦的是，TEXT或BLOB类型的字段必须指定前缀长度才能建索引，很多新手在这一步直接报错。
我自己在做慢查询分析时，发现不少SQL的问题不在写法，而在字段类型导致优化器估算行数偏差巨大。比如状态字段用varchar(20)存0和1，统计信息对字符串的唯一值估算不准，优化器可能选错执行计划。所以后面我总结出一个习惯：在建表之前，先对着字段清单逐一问自己，这个字段到底该用数值还是字符串，到底需要多长，到底要不要参与排序和查询。
2. 数值类型：别只看整数还是小数
2.1 整数类型的选择与显示宽度
MySQL的整数类型有TINYINT、SMALLINT、MEDIUMINT、INT、BIGINT，区别就是存储字节数和取值范围。很多教材喜欢列一个范围表，但实际业务中，你更需要关注的是“这个字段的取值天花板在哪里”。
我见过有人用INT存IP地址，有人用BIGINT存状态值，还有人给自增主键用INT UNSIGNED，结果随着业务增长到了40亿上限，差点出大事。经验是：状态码、枚举值、布尔值，用TINYINT；数量、序号，用INT；订单号、雪花ID、大表的自增主键，直接用BIGINT。不要吝啬这两个字节，换个类型重演一遍数据迁移，成本高得多。
这里还要提一下“显示宽度”，也就是INT(11)这种写法。很多初学者以为INT(4)就是最多存4位数，其实完全不是。显示宽度只影响ZEROFILL时的补零显示，不影响存储范围和计算。这个脑补很常见，但属于复习文档里不太会强调的细节。既然MySQL 8.0已经废弃了显示宽度，新项目就别写INT(11)这种古董写法了。
2.2 DECIMAL 与 FLOAT/DOUBLE 的真相
业务里凡是涉及金额、汇率、体重、库存等需要精确计算的数值，记住一条铁律：不要用FLOAT和DOUBLE。原因很简单，它们是用二进制近似存储浮点数的，0.1 + 0.2的结果可能不是0.3。做电商系统时，如果金额用DOUBLE，累计对账迟早会出分分钱对不上的问题。
正确的选择是DECIMAL，比如DECIMAL(10,2)表示总位数10位、小数位2位，最大能存到99999999.99。它的底层实际上是字符串存储的整数部分和小数部分，虽然计算性能比原生浮点差一点，但在金融、交易场景下，精度比性能更重要。对于大额金额，可以把小数位设为4，或者把金额换算成分用BIGINT存储，这也是一种常见方案。
我踩过一次坑：报表统计大量金额求和时，SUM一个DECIMAL字段返回结果正常，但中间如果叠加了FLOAT类型的折扣比例，最终结果出现了诡异的误差。后来排查发现，某个折扣字段是老系统遗留的FLOAT类型。从那以后，我处理任何数值计算时，都会先检查类型链，确保不会混入浮点类型。
2.3 无符号与自增主键的细节
整数字段还有一个容易被忽视的修饰符：UNSIGNED。它表示非负数，取值范围直接翻倍，适合年龄、库存、数量这样不可能为负的字段。但要注意，UNSIGNED不是银弹。如果表里的字段涉及减法运算，比如库存 - 购买数量，一旦结果可能为负，数据库会报错或截断，业务逻辑反而要额外处理。
自增主键就更典型了。InnoDB的主键选择有严格规则：优先使用非空唯一索引，如果你没有明确主键，它可能生成隐藏主键。所以自增主键通常用BIGINT UNSIGNED，别用INT。我之前处理过一个日志表，最初用INT UNSIGNED做主键，跑了几年后接近最大值，半夜告警“主键溢出”，最后只能停机改表结构，折腾了几个小时。如果当初建表时就想到数据增长规模，完全可以避免这场事故。
3. 字符串与二进制类型：CHAR、VARCHAR与TEXT
3.1 CHAR与VARCHAR的底层差异
字符串类型里最常用的是CHAR和VARCHAR。CHAR(N)是定长字符串，长度不够会在右边补空格，取出时再去除空格；VARCHAR(N)是变长字符串，额外用1到2个字节记录实际长度。定长的好处是存储和访问更稳定，适合MD5、UUID、状态码、身份证号这类固定长度的数据。变长则适合长度变化大的文本。
实际建表时，很多同学看到“定长性能好”就到处用CHAR。其实在InnoDB中，CHAR和VARCHAR的行存储格式差异没那么大，关键是避免歧义。比如你给会员卡号用CHAR(10)，但业务里偶尔会插入长度为8的卡号，MySQL会补两个空格，取出来做拼接时如果忘了TRIM，就会莫名多出空格。反而用VARCHAR更安全。
3.2 VARCHAR长度定义不是字符个数那么简单
VARCHAR(255)和VARCHAR(64)的区别，很多人只当成长度限制，却没想过它直接影响了索引使用。以utf8mb4为例，每个字符最多占4个字节，VARCHAR(255)最大可能占用1020字节，再加2字节长度位。如果在这个字段上建索引，InnoDB的索引键长度限制（默认3072字节）下，单列索引还能建，但一旦要做复合索引，长度很容易超标。
另一个细节是：MySQL的VARCHAR(N)里的N指的是字符数，不是字节数。这在中文场景非常容易混淆。VARCHAR(20)可以存20个汉字，也可以存20个英文字母，而不是只能存20个字节。很多人以为一个汉字占3个字节，所以VARCHAR(20)只能存6个汉字，这是完全错误的理解。
还有关于“255”这个数字的来历，很多老项目中到处是VARCHAR(255)，其实在早期版本中，255刚好满足某些索引前缀的字节限制，而且旧版MySQL对VARCHAR长度的处理有阈值。到现在，无脑255已经是坏味道。正确的做法是：根据业务枚举、名称、地址的实际长度范围精确设置。比如用户名用VARCHAR(32)，手机号用VARCHAR(11)，URL用VARCHAR(2000)，而不是所有字段一刀切255。
3.3 TEXT/BLOB的存储陷阱
TEXT和BLOB都是大对象类型，区别是TEXT按字符存储、有字符集，BLOB按字节存储、没有字符集。它们适合存文章正文、二进制文件等。但很多人不知道，InnoDB的TEXT字段如果长度超过一定阈值，会存储在外部页中，而不是和普通字段放在同一个数据页。查询时如果SELECT里带了TEXT字段，意味着可能需要额外的外部页读取，性能影响不小。
另外，TEXT类型不能有默认值（除非你启用了比较新的特性），也不能直接建非前缀索引。如果你需要根据文章标题或摘要做索引，应该拆出独立的VARCHAR字段，或者用生成的列。实际业务中，我通常会建议把大文本拆到单独的子表或独立的存储服务，主表只保留必要元数据，尽量不要在核心业务表里堆TEXT。
3.4 字符集与排序规则collation的影响
字符串类型一定离不开字符集问题。MySQL的字符集由数据库、表、字段、连接等多个层级控制，一个不小心就会出现中文乱码。最常用的是utf8mb4，注意不是utf8，因为MySQL的utf8其实是utf8mb3，只支持3字节的字符，存不了emoji和一些生僻汉字。很多人在表情符号出现后才被迫把表改成utf8mb4，还引发过一次全表重建。
排序规则collation同样值得留意。utf8mb4_general_ci和utf8mb4_unicode_ci是常见选择，前者性能略好，后者对Unicode排序更精确。如果是区分大小写的用户名或订单号，需要使用utf8mb4_bin或utf8mb4_0900_as_cs。我做过一次小范围用户导入，因为排序规则不一致，两张表的同名字段在JOIN时无法高效使用索引，导致关联查询走了临时表，直到我统一了排序规则才恢复速度。
4. 日期时间类型：时区、精度和业务坑
4.1 DATETIME 与 TIMESTAMP 的选择
日期时间类型最常用的两个就是DATETIME和TIMESTAMP。很多人只知道TIMESTAMP的范围较小，其实它们最大的区别是时区处理。TIMESTAMP存储的是UTC时间戳，会跟随数据库的time_zone设置进行转换；DATETIME则是原样存储，不带时区信息。
如果你的业务面向全球用户，记录“用户下单时间”时，我会更推荐TIMESTAMP，这样在不同时区的服务器之间迁移数据时，时间能够正确转换。但反过来，如果你的业务只需要记录“某日某时”这种绝对时间，不关心时区，比如开奖时间、活动开始时间，用DATETIME更省心。我见过很多团队把TIMESTAMP和DATETIME混着用，最后统计报表时出现8小时偏差，反复排查后才发现是时区配置不一致。
4.2 TIMESTAMP 的2038年问题与范围
TIMESTAMP的范围是1970年到2038年，看起来很远，但有些系统设计的生命周期确实会超过30年。央行、社保、保险这类领域的核心表，如果用TIMESTAMP，到了2038年就是又一次“千年虫”危机。更麻烦的是，TIMESTAMP在旧版本MySQL中还受TIMESTAMP列数量、默认值等限制，虽然新版本放宽了，但范围上限没有变。
所以在设计长期存储的架构时，建议直接把时间字段定义为DATETIME(3)或者BIGINT毫秒时间戳，避免未来某一天突然溢出。DATETIME的范围是1000年到9999年，对绝大多数业务足够。如果你要精确到毫秒，用DATETIME(3)；如果要精确到微秒，DATETIME(6)也能支持。就是别把所有时间都塞进整秒级别，很多接口排序场景下毫秒精度能避免很多“奇怪”的交叉。
4.3 时间精度与默认值：ON UPDATE
MySQL 5.6以后，日期类型可以支持小数秒，比如DATETIME(3)表示毫秒精度。设置默认值也有更合理的写法，比如DEFAULT CURRENT_TIMESTAMP(3)，在插入时自动填入当前时间。更新时如果需要自动刷新修改时间，可以加ON UPDATE CURRENT_TIMESTAMP(3)，这样每次UPDATE都会自动更新该字段，省去业务代码里手动赋值。
但是要注意：如果你同时给创建时间和更新时间都设置了自动填充，批量导入数据时，导入工具可能会主动为这两列指定值，导致自动填充失效。这种场景下，反而应该把自动填充和显式赋值区分开，或者导入前临时去掉ON UPDATE。我遇到过数据迁移后所有记录的updated_at都变成同一个值的情况，就是因为INSERT ... ON DUPLICATE KEY UPDATE的更新逻辑触发了ON UPDATE，覆盖面超出预期。
5. JSON 与枚举、集合类型要慎重
5.1 JSON 类型适合什么场景
MySQL 5.7开始支持原生JSON类型，这给存储半结构化数据带来了很大便利。比如用户扩展信息、商品规格参数、第三方回调原始报文，都可以用一个JSON字段存下来，免去大量的并列扩展字段。JSON类型的优势是，插入时会自动校验JSON格式合法性，存储时会做二进制序列化，读取时不需要每次都解析文本。
我在项目里用JSON存消息推送的扩展内容，确实很方便。但要说清楚的是，JSON不是用来替代关系建模的。如果某个属性需要频繁用于WHERE过滤、GROUP BY分组或者JOIN关联，那它不应该藏在JSON里。因为对JSON字段的查询，即使你为它建了多值索引或生成列索引，性能和常规字段直接比还是有差距。
5.2 JSON 的索引限制与替代方案
对JSON字段本身是不能直接建索引的，但可以通过“生成列”把里面的某个键提取出来，再对这个生成列建索引。比如有一个user_profileJSON字段，里面包含age，你可以建一个age生成列并加索引。这种方案能用，但代价是每次写入都要额外计算生成列。
更常见的做法是：把高频查询的字段从JSON中拆出来，单独建成普通列。JSON只留低频扩展属性。比如订单表，把订单状态、支付方式拆成独立字段，把“用户备注”“扩展参数”放在JSON。这样既保留灵活性，又不牺牲查询性能。不要一开始就指望靠JSON函数的高性能，那只是方便，不是万能。
5.3 ENUM/SET 类型需谨慎使用
ENUM和SET在MySQL里算冷门，但偶尔能看到。ENUM是枚举类型，存储时实际使用的是内部索引值，修改枚举列表需要ALTER TABLE；SET是集合类型，可以同时选多个值。它们能节省存储空间，但代价是灵活性差、排序语义特殊、迁移风险高。
比如性别字段用ENUM('男','女','未知')，看起来很好，但后续业务要加一个“保密”选项，你必须执行一次ALTER TABLE修改枚举定义。如果应用层和数据库层的枚举定义没有同步维护，很容易插入非法值。更麻烦的是，ENUM的排序是按照内部索引顺序而不是字符串字典顺序，查询结果可能不符合直觉。所以除非你非常清楚这些限制，否则我更推荐用TINYINT配合后端字典表，或者用VARCHAR存短代码。
6. 实操总结：一张表的数据类型选型清单
6.1 常见业务字段对应的类型建议
根据自己的项目经验，我整理了一张常见字段选型表，可以直接拿来参考。这张表不是绝对的，但能帮你避开大多数新手误区。
| 业务含义 | 推荐类型 | 说明 |
|---|---|---|
| 主键ID | BIGINT UNSIGNED | 自增或雪花ID都够用 |
| 用户状态、枚举值 | TINYINT | 0/1/2等，别用字符串存 |
| 手机号 | VARCHAR(20) | 考虑国际区号和格式，不用整数 |
| 邮箱 | VARCHAR(64) | 长度根据业务控制 |
| 金额 | DECIMAL(10,2) | 必须精确保留小数 |
| 库存、数量 | INT UNSIGNED | 一般不会为负 |
| 订单状态码 | TINYINT或VARCHAR(2) | 建议用数字字典 |
| 标题/名称 | VARCHAR(64)或VARCHAR(128) | 按最长情况留余量 |
| 描述/备注 | VARCHAR(500)或TEXT | 如果超过500建议拆表 |
| 创建时间 | DATETIME(3) | 保存毫秒，避免前后颠倒 |
| 扩展信息 | JSON | 低频非查询条件字段 |
| URL | VARCHAR(2048) | 如果超长只存摘要 |
这张表背后的逻辑是：能选数值就不选字符串，能用定长就不选变长，能用短字段就不选长字段。你不需要记住每个类型的字节数，但需要养成“按需定义”的习惯。
6.2 改表迁移时如何安全变更类型
项目上线后，难免遇到需要改字段类型的情况。这个操作比新建表风险大得多，因为ALTER TABLE往往会重建表，锁表时间可能很长。如果你在业务高峰期执行一个ALTER TABLE MODIFY，几条大表就可能拖垮整个服务。
安全的做法是使用MySQL 5.6以后提供的在线DDL特性，ALGORITHM=INPLACE和LOCK=NONE。但并不是所有改类型都支持在线操作，比如把VARCHAR改成TEXT或修改字符集，有时候还是需要拷贝表。我一般建议先在测试环境用大表模拟一次变更，统计执行时间，再决定是否分批处理。如果表实在太大，可以借助pt-online-schema-change或gh-ost这类工具，在后台以触发器或Binlog方式同步增量数据，从而减少锁表影响。
对于类型变更本身，也要注意顺序。例如你要把VARCHAR改成INT，先要保证现有数据都能被正确转换，否则ALTER会失败并回滚。另一点是，变更后可能影响索引和默认值，记得一并检查和调整。我通常会写一个变更前数据合法性检查SQL，提前排查异常值，避免半夜被数据库报错叫醒。
我自己做MySQL设计时一直遵循一个原则：字段类型不追求最省空间，而是要匹配真实业务语义，并预留一定的变化余量。与其在复盘会上解释当初为什么用VARCHAR(255)存状态，不如提前花十分钟想清楚每个字段将来可能出现的取值。数据库可以优化SQL、调整索引，但一个设计糟糕的类型往往要付出十倍代价才能纠正。借着这篇文章，希望你下次建表时，能对自己的每个字段类型都说一句“我知道它为什么是它”。
