MySQL数据类型选型实战：避免精度丢失与索引失效的坑

说实话，MySQL的数据类型这个主题，网上教程一抓一大把，但多数是把官方文档翻译了一遍，告诉你“INT是整型，VARCHAR是字符串，DATETIME是时间”，看完了该踩的坑一个没少踩。

我为什么想写这篇？因为这些年接手过不少“看起来能跑、一上线就出问题”的库表，最后排查下来，问题根源往往不是SQL写得烂，而是建表那一刻数据类型就没选对。类型一旦定死了，后面所有查询、索引、应用代码都得围着它转，想改？一张几百万行的表，一个ALTER TABLE下去，锁表时间够你喝三杯咖啡。

所以这篇不是给你背语法用的，而是把这些年在数据类型上踩过的坑、复盘过的线上事故、以及最后沉淀下来的选型逻辑，一次性讲清楚。适合正在学MySQL的初学者，也适合写了好几年SQL但从来没认真想过“为什么这个字段用INT不用BIGINT”的开发者。

1. 为什么类型选错比SQL写错更难定位

很多人觉得，数据类型不就是“能存就行”吗？整数用INT，小数用DECIMAL，字符串用VARCHAR，时间用DATETIME，按部就班不就行了？

问题是，真实业务里的数据类型选择，远不是这张对照表能解决的。选错了不会立刻报错，它会在某个你不注意的时刻，以极其隐蔽的方式反咬你一口。

1.1 一次让我印象深刻的余额对账事故

之前帮一个做电商的朋友排查线上问题，现象是：财务对账时发现，有一小部分订单的金额加总后，和支付通道的结算单差了那么几分钱。不是固定差，是时差时不差，完全摸不着规律。

排查到最后，问题出在订单表的amount字段上——建表的人图省事，用了FLOAT。

你可能会说，FLOAT不就是浮点数吗，存金额有什么问题？问题大了。FLOAT和DOUBLE是二进制浮点数，它内部是用科学计数法以2为底存储的。像0.1这种在十进制里无比正常的数，转成二进制后是一个无限循环小数，存储时只能截断，于是就有了精度误差。

单笔订单几分钱的误差确实不起眼，但当你对几千几万笔订单做SUM()聚合时，误差就会累积、放大，最终变成对不上的那几分钱。更麻烦的是，这种误差是随机的，你很难通过“多退少补”之类的规则去修复。

那笔订单表后来改成DECIMAL(10,2)重刷了一遍历史数据，这才彻底消停。

1.2 类型决定了存储、索引和比较这三件大事

很多人对数据类型有个误解，觉得它只是“规定存什么格式的数据”。实际上，数据类型在MySQL里至少同时决定了三件大事：

存储空间和行大小。 InnoDB默认一个数据页是16KB，一行的数据要尽量塞进一个页里才能减少IO。如果字段类型偏大，比如user_id用了VARCHAR(64)，而实际只存9位数字，每行就会白白多占几十字节。一张千万行的表，光这一个字段就多出几百MB甚至上GB的存储，查询时的IO开销也随之暴涨。

索引的效率。 类型越长，索引树里每个节点能存放的键值就越少，树的层级就越深。B+Tree每深一层，就意味着查询时多一次磁盘寻址。这也是为什么主键强烈建议用BIGINT而不是VARCHAR(64)的随机字符串——后者不仅长，而且无序，会导致页分裂频繁、索引碎片化严重。

比较的规则。 MySQL在比较两个值时，会根据数据类型决定用什么样的规则。如果两边类型不一致，MySQL会做隐式转换。一旦转换的方向和你想的不一样，就可能出现“明明条件正确，但就是查不出数据”的诡异情况。这个我在后面第5章会专门展开讲。

1.3 从一张错误的建表语句说起

下面这张表，是我从一个真实项目里简化出来的，它几乎把能踩的雷全踩了：

sql复制CREATE TABLE `user_order` (
  `id` INT(11) NOT NULL AUTO_INCREMENT,
  `user_phone` VARCHAR(100) DEFAULT NULL,
  `status` TINYTEXT,
  `amount` DOUBLE(10,2) DEFAULT NULL,
  `create_time` VARCHAR(30) DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

看着是不是很眼熟？我来讲讲这张表的问题：

• user_phone用VARCHAR(100)存手机号，手机号就11位，你需要100个字符干嘛？白白浪费89个字符的存储和索引空间。
• status用TINYTEXT，这类型连默认值都不能设置，而且TEXT类型在InnoDB里通常需要额外的行外存储，查询时多一次间接寻址。
• amount用DOUBLE(10,2)——就是1.1节那个事故的翻版，金额精度根本保不住。
• create_time用VARCHAR(30)存时间，这是我最不能忍的。字符串存时间至少有三大问题：无法使用时间函数直接计算、无法利用时间索引做范围扫描、而且输入格式全靠自觉，存进去2026-01-01和2026/01/01混着来，你排序试试？

这张表如果上了生产，每一列都是一颗定时炸弹。下面几章，我会逐一说明正确的做法是什么，以及背后的原理。

2. 数值类型选型：范围、精度和显示宽度的三笔账

数值类型是所有类型里最需要“算账”的。建表前你至少要回答三个问题：最大值会不会超边界？需不需要小数？小数需要多精确？

2.1 INT的边界和那个坑人的INT(11)

MySQL的整数类型一共有五种，按存储空间从小到大排分别是TINYINT(1字节)、SMALLINT(2字节)、MEDIUMINT(3字节)、INT(4字节)、BIGINT(8字节)。

它们的取值范围，有符号和无符号差别很大。我习惯记最大值：

先说个流传甚广的误区：INT(11)这个11，不是指“最多只能存11位数”。

这个叫“显示宽度”，在早期MySQL版本里，它配合ZEROFILL属性，作用是当数值长度不足11位时，在前面补0补齐到11位。比如INT(5) ZEROFILL存个123，查询出来的结果是00123。它不影响存储范围，INT(3)和INT(15)能存的最大值完全相同。

更坑的是，从MySQL 8.0.17开始，这种整数类型的显示宽度已经被官方移除了，你再写INT(11)，MySQL会直接忽略括号里的数字，甚至给你一条warning。所以现在建表，直接写INT就完事，千万别再纠结带不带数字了。

那到底什么时候用无符号UNSIGNED？

我的判断标准很简单：这个字段未来有没有可能为负？ 如果绝对不可能为负，比如age、quantity、level这类，就用UNSIGNED。它相当于把负数那边的存储空间砍掉，挪给正数用，让正数上限翻倍。

但我必须提醒你：不要在创建表的时候轻易设计“INT UNSIGNED减去INT UNSIGNED”这类运算。因为两个无符号数相减的结果如果是个负数，MySQL会报错：BIGINT UNSIGNED value is out of range。这是真实的线上坑——曾有人做库存扣减时用无符号数直接相减，库存不足的场景下整个接口直接崩了。如果业务里有减法运算，宁可用有符号的INT或BIGINT。

2.2 金额为什么必须用DECIMAL而不是FLOAT/DOUBLE

这个坑在1.1节已经埋了伏笔。这里我把底层原因讲透。

FLOAT和DOUBLE是近似值存储，DECIMAL是精确值存储。为什么？因为DECIMAL在MySQL内部是以字符串形式存储十进制数字的，它不会做二进制的浮点转换，所以十进制小数在它里面不会产生精度损耗。

举个例子，下面这段SQL的结果可能会让你意外：

sql复制SELECT 0.1 + 0.2;

在MySQL的默认设置下，结果是0.3没错——因为它默认对DECIMAL和字符串常量做了精确处理。但如果你的列类型是DOUBLE，情况就变了：

sql复制CREATE TABLE t (a DOUBLE, b DECIMAL(10,2));
INSERT INTO t VALUES (0.1, 0.1);
SELECT a + 0.2, b + 0.2 FROM t;

a + 0.2的结果很可能是0.30000000000000004，而b + 0.2的结果才是正常的0.30。这就是二进制浮点数精度误差的直观体现。

所以，凡是涉及金额、费率、余额等需要精确计算的字段，一律用DECIMAL。DECIMAL(M,D)里的M是总位数（精度），D是小数点后的位数（标度）。比如DECIMAL(10,2)表示最多8位整数加2位小数，也就是最大能存99999999.99，约1亿。如果业务金额可能破亿，就果断用DECIMAL(12,2)甚至DECIMAL(14,2)，别抠这几位，因为一旦溢出，MySQL只会给你一条warning然后静默地把值截断成最大值，这个warning在生产环境里经常被忽略——数据错了还不报错，这才是最可怕的。

2.3 自增主键选INT还是BIGINT？

我的建议是：从2026年的视角看，新表主键直接上BIGINT，别再用INT了。

为什么？我用计算给你看。INT UNSIGNED最大值是42.9亿，听起来很多是吧？如果你的业务每天产生10万条订单，42.9亿能撑多少天？

4294967295 ÷ 100000 ÷ 365 ≈ 117年。

这么看确实够用。但问题是，真实业务里主键的自增ID不是只有订单表在消耗。你有日志表、流水表、操作记录表，一旦某张表上了缓存、归档、分库分表方案，原来的INT主键会立刻变成瓶颈。尤其是分表后，如果用“原表主键+分表因子”做联合唯一键，INT的范围就更紧张了。

而且主键类型还直接决定了二级索引的存储大小——InnoDB的二级索引叶子节点存的是主键值。你主键用BIGINT还是INT，直接影响了这张表所有索引的体积。BIGINT比INT多4字节，单看不多，但二级索引多的话，放大效应很明显。

我自己现在的习惯是：核心业务表一律BIGINT UNSIGNED AUTO_INCREMENT，宁可存不满，不要不够用。 迁移一次主键类型的成本，比多出来的那点存储贵上百倍。

3. 字符串类型选型：先算字节再谈CHAR与VARCHAR

字符串类型看起来简单，实际上里面藏着不少细节。尤其是utf8mb4成为默认字符集之后，很多以前“够用”的配置现在都不够用了。

3.1 判断“VARCHAR(255)够不够用”之前，先搞清楚你存的是什么

很多人一看到字符串就写VARCHAR(255)，因为“大家都这么写”。但VARCHAR(n)里的n，指的是字符数，不是字节数。而MySQL实际存储时按字节算空间的，行大小限制也是按字节算的。

在utf8mb4字符集下，一个字符最多占4字节。也就是说，一个VARCHAR(255)的字段，在最坏情况下需要255 × 4 = 1020字节的存储空间。

InnoDB一个数据页16KB，而单行记录的最大大小大约是65535字节（不包括TEXT/BLOB的行外存储部分）。如果你建了一张表，里面放了三四个VARCHAR(255)的字段，加上其他字段，很容易就逼近甚至超过这个行大小上限。到时候MySQL会直接报错：

code复制ERROR 1118 (42000): Row size too large. The maximum row size for the used table type, not counting BLOBs, is 65535.

更实用的一个经验是：如果字段长度需要超过255个字符，不要直接上VARCHAR(500)、VARCHAR(1000)，先想想是不是该用TEXT；如果字段长度必然超过几十个字符且不打算建索引，直接用TEXT也许更省心。

VARCHAR有个“最长能建索引的前缀”问题：InnoDB里索引键长度限制是768字节（MySQL 5.6以前）或3072字节（5.7以后，视行格式而定），utf8mb4下一个VARCHAR(255)做索引需要1020字节，如果全部字段都建索引，很容易超限。

3.2 CHAR和VARCHAR的取舍，不只是“定长和变长”的区别

教科书里会说：CHAR是定长字符串，VARCHAR是变长字符串。这没错，但不足以指导真实选型。

CHAR的底层逻辑是：分配固定的存储空间，存的时候如果不够长，尾部用空格补齐。查询取出时，MySQL会去掉尾部空格。所以有几个特点：存取速度相对快（不需要额外记录长度信息，也不存在碎片问题），空间固定容易计算，但如果你存的是长度波动很大的内容，空间浪费非常严重。

VARCHAR的底层逻辑是：在真实字符串内容前面，额外用1~2字节记录这个字符串的长度（最长65535字符，所以255以内用1个字节记录长度，超过就要用2个字节）。它的存储是紧凑的，但行内会出现长度不一的情况，UPDATE时如果新值比旧值长，就可能发生“页内移动”或“行迁移”，带来额外的IO。

我这些年总结下来的选择标准：

• 短且固定或接近固定的标识符，如MD5哈希值、订单号、身份证号，用CHAR。这里的“长度固定”指这些值永远是同一长度，CHAR不会浪费，还能省掉VARCHAR的长度前缀字节。
• 长度差异大、长度不定、经常UPDATE的内容（比如用户昵称、备注、简介），用VARCHAR。
• 长度极小、只有几个固定值的枚举场景，比如'Y'/'N'这类标志位，用CHAR(1)。这个场景里CHAR(1)比TINYINT的语义更清晰，比VARCHAR(1)更省一个长度字节。

3.3 TEXT类型绝不是“大号VARCHAR”，它的代价你承受不起

先给出暴论：凡是逻辑上不需要超过几千字符的字段，都不要用TEXT。

很多人觉得TEXT方便，能存很长的内容，而且VARCHAR最多只能65535字符。但TEXT有几个绕不开的代价：

第一，TEXT/BLOB类型的字段不能有默认值。MySQL 8.0依然如此，你写content TEXT DEFAULT ''直接报错。这就意味着你每次INSERT的时候，哪怕暂时没有内容，也必须显式给这个字段一个空字符串，业务代码稍不注意就会变成SQL里漏字段。

第二，TEXT类型在InnoDB里默认有“行外存储”的机制。当TEXT字段的内容超过一定阈值（具体和行格式有关），InnoDB会把数据放到溢出页里，行内只保留一个20字节左右的指针。这会导致查询这个字段时，可能要从多个数据页里捞数据，随机IO次数增加。

第三，TEXT类型不能直接建普通索引。你必须指定前缀长度，比如INDEX idx_content (content(20))。这个索引只能帮你做前缀匹配的查询优化，内容一长就失效了。

如果确实需要存长文本，比如文章正文、日志详情，我一般这么设计：

• 如果只是存、很少需要回表查出来用，字段类型用MEDIUMTEXT或LONGTEXT可以接受。
• 如果经常需要按时间、作者等维度做查询，把这些维度单独拆成普通列，主表只和TEXT字段做“懒加载”关联——也就是列表页只查非TEXT字段，点进详情再查TEXT字段。
• 更高端的做法是：长文本直接放到对象存储或单独的文档系统里，MySQL里只存一个URL或者对象ID。

4. 时间类型选型：DATETIME和TIMESTAMP不是随便二选一

我不知道为什么MySQL里时间类型是我见过被误用得最多的类型，明明有专门的DATE/DATETIME/TIMESTAMP，很多人就是喜欢用VARCHAR存时间。这一章我不只讲三者的区别，还讲清楚各自的适用场景和背后的坑。

4.1 三种时间类型的核心参数对比

先上对比表：

关键的几点，我说一下为什么这么设计：

DATETIME存的就是字面时间。 不管你数据库时区怎么改，你当初存进去的2026-06-01 12:00:00，查出来还是2026-06-01 12:00:00。它在MySQL内部是按“YYYYMMDDHHMMSS”的整数形式存的，不带任何时区信息。

TIMESTAMP内部存的是UTC时间戳。 插入的时候，MySQL会把当前会话时区的时间转换成UTC秒数存起来；查询的时候，再按当前会话时区转回当地时间。这意味着，如果你的应用部署在东八区，同一行数据在另一个设置为UTC的会话里查出来，时间会差8小时。“自动转换”听起来很美好，但也意味着当你的业务方分布在多个时区时，TIMESTAMP列在不同时区下查询结果天然不同。这既是特性，也是坑——我曾见过有团队把TIMESTAMP当作“可以自动按用户时区显示”的时间字段用，结果发现显示逻辑完全不受应用控制，数据在不同报表里对不上，排查了很久才发现是会话时区不一致导致的。

顺带说一句，TIMESTAMP还有一个几乎所有的教程都会提、但还是有人中招的2038年问题。它的上限是2038年1月19日凌晨3点14分07秒（UTC），超过这个时间就溢出报错了。别看现在才2026年，有些业务系统要存“有效期到2050年”的会员卡、长期合同之类的时间，用TIMESTAMP直接废了。DATETIME的存储范围到9999年，没有这个问题。

4.2 实践建议：多数业务表的时间字段应该这样设计

我的默认方案，基本可以覆盖90%以上场景：

• 业务时间字段，比如下单时间、支付时间、创建时间，一律用DATETIME，并明确指定精度。
  MySQL 5.6.4以后，DATETIME和TIMESTAMP都支持fsp（小数秒精度）参数。如果你不需要毫秒级，就用DATETIME默认不带小数秒，存8字节就够；如果你需要毫秒级别的精度（比如在极短时间内判断先后顺序），那就用DATETIME(3)。坦白说，多数互联网业务用秒级时间就够了，别为了“精确”盲目上DATETIME(6)，除了把每行记录撑大、让索引更大，对业务没任何帮助。

• 需要自动记录插入时间和更新时间，可以在建表时直接把默认值和ON UPDATE写上。

sql复制CREATE TABLE `order` (
  `id` BIGINT UNSIGNED NOT NULL AUTO_INCREMENT,
  `create_time` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
  `update_time` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

其中ON UPDATE CURRENT_TIMESTAMP是让MySQL在行数据被UPDATE时自动刷新这个字段，省得应用层每次手动维护更新时间。注意：只有DATETIME或TIMESTAMP类型且默认值是CURRENT_TIMESTAMP时，这个语法才支持，VARCHAR就别想了。

• 跨时区、希望统一存UTC时间的场景，我会用DATETIME，但在连接串或会话里统一设置time_zone = '+00:00'，所有时间按UTC存取，应用层负责转换展示。 这样既不丢精度，也不依赖TIMESTAMP的隐式转换逻辑，全局行为最好控制。

4.3 查询时最大的坑：在时间字段上套函数

数据类型选对了时间类型还不够，很多人查询时不注意写法，照样能把索引废掉。

比如你有这样一条SQL：

sql复制SELECT * FROM `order` WHERE DATE(create_time) = '2026-06-01';

这段SQL的逻辑是没错，但它意味着MySQL必须对create_time这一列每一行都执行一次DATE()函数，算完之后才能和右边的常量比较。函数的存在让索引完全失效，最后只能全表扫描。

正确的写法是用范围查询：

sql复制SELECT * FROM `order` 
WHERE create_time >= '2026-06-01 00:00:00' 
  AND create_time < '2026-06-02 00:00:00';

这样MySQL可以直接在DATETIME的B+Tree索引上做范围扫描，效率差距在百万行级别的表上，是几十毫秒和几秒的差别。

5. 容易被忽略的隐性炸弹：隐式转换、字符集错位与NULL滥用

前四章讲的都是建表时“怎么选”，这一章重点讲“类型选完之后，还有哪些行为会悄悄毁掉你的SQL性能”。

5.1 隐式类型转换：一个字符串和一个数字之间，MySQL听谁的？

先看一个非常经典的“翻车”案例。

有一张用户表，user_id字段是VARCHAR(20)，里面存的是纯数字字符串，比如'10086'。你在业务里查询：

sql复制SELECT * FROM user WHERE user_id = 10086;

这条SQL不会报错，会正常返回结果。但如果你在user_id上建了索引，这条SQL用不上索引——因为MySQL的隐式转换规则里，字符串列与数字常量比较时，会把字符串列转成数字，于是user_id列上的每个值都被隐式地做了CAST(user_id AS SIGNED)操作，索引自然就失效了。

查询计划里你会看到type: ALL，也就是全表扫描。一张百万级的用户表，就这么一条简单的等值查询，硬生生被拖成几百毫秒。

解决办法有两条：

• 应用层查询时，把参数带上引号，写成WHERE user_id = '10086'，让两边都是字符串，就不会触发隐式转换。
• 更根本的：如果这个字段在业务上确实是纯数字，当初就不应该用VARCHAR，直接建表为BIGINT或INT。 这一条再次回到了第1章的核心主题——类型选对，能省掉应用层无数的补丁逻辑。

再补充一个常见案例：status字段如果定义成TINYINT，而代码里查询时传了个字符串'1'，在MySQL 5.7及以上版本，把字符串常量'1'和数值列比较时，MySQL会尝试把字符串转成数值，大多数情况下没问题，但如果字符串里有非数字开头的值，转换结果会变成0，和你预期的数据风马牛不相及。

5.2 字符集不一致导致的JOIN隐式转换，慢得悄无声息

开发环境里通常不会出问题，因为所有表都用默认的utf8mb4、utf8mb4_0900_ai_ci（MySQL 8.0）或utf8mb4_general_ci（MySQL 5.7）。但涉及老项目、不同来源导入的数据表时，很可能出现一张表的字段是utf8mb4，另一张关联表的字段还停留在latin1或utf8mb3。

这种情况下做JOIN，MySQL必须先把一边的字符集转换成另一边才能比较，于是索引又用不上了，甚至可能报错“Illegal mix of collations”。

排查方法很直接：

sql复制SELECT TABLE_NAME, COLUMN_NAME, CHARACTER_SET_NAME, COLLATION_NAME
FROM information_schema.COLUMNS
WHERE TABLE_SCHEMA = 'your_db'
  AND DATA_TYPE IN ('char','varchar','text');

平时建表养成一个习惯：所有库表统一字符集，统一排序规则。我个人的默认配置是utf8mb4 + utf8mb4_0900_ai_ci（8.0）或utf8mb4_unicode_ci（5.7及低版本，排序规则选unicode是为了更精确地按Unicode规则排序，而不是简单的字节比较）。不要在单张表、单个字段级别去“优化”字符集，不同字符集带来的存储节省，远小于它引发的JOIN混乱和排序异常造成的代价。

5.3 NULL不是“没有值”那么简单，它会让索引统计失真

NULL在MySQL里是一个很特别的存在。很多人刚学SQL时，知道NULL和''不同，但这只是最浅的一层。

说几个我观察到的现象：

COUNT(column)和COUNT(*)结果不同。 COUNT(*)会统计所有行，COUNT(某列)会忽略该列为NULL的行。曾经有人写报表SQL，统计“有多少用户填写了手机号”，用的是COUNT(phone)，如果部分行phone是NULL，统计出来的数字天然就会偏小，不是SQL写错了，而是对NULL的语义理解不对。

NULL对索引的影响被许多人高估或低估。 MySQL 8.0之前的版本，一个多列索引里如果某行索引列有NULL值，该行不会被计入索引（准确说，NULL值的索引项依然存在，但优化器对IS NULL的优化较弱）。而在5.7和8.0里，IS NULL也有机会走索引。真正让人头疼的是，如果一个字段大部分值是NULL，索引的区分度会变差，优化器可能直接放弃这个索引。

NULL会让比较逻辑变得极其容易出错。 任何和NULL做算术或比较运算，结果都是NULL。比如price * discount，如果discount是NULL，结果就是NULL；WHERE price > 100永远筛选不出price为NULL的行——因为NULL和100比较结果是“未知”，不是“假”。所以经常出现“明明有这条数据，查不出来”的诡异现象。

所以在设计表的时候，我强烈建议：能NOT NULL的字段都加NOT NULL，空值用默认值代替。 比如数值型默认0、字符串默认空字符串''、时间要么允许为NULL（因为有些业务确实“未发生”），要么用'1970-01-01 00:00:00'这类业务哨兵值。这样做的最大好处是逻辑规则清晰，无论查询还是统计，都不用考虑“这里会不会有NULL”这种边界。

有人担心“把默认值设成0，语义上不就不准确了吗？”这个问题可以通过注释解决。建表时给每个字段写清楚注释：remark列写“0表示未填写，1表示已填写”。类型和注释一起规定好，数据库的语义边界就清楚了。

收尾的一点个人习惯

最后分享一个我用了很久的土办法。

每次建表前，我会把每个字段在实际业务里可能出现的最大最小值列一遍，然后对照MySQL的边界值，看是否富余。比如订单金额，一天最多百万级，每笔不超过999999.99，那就选DECIMAL(10,2)；比如用户ID，日活在千万之内，未来五年不会超过21亿，可以用INT UNSIGNED，但考虑到系统要跑十年以上，还是直接BIGINT。把这个思路写到建表SQL的注释里，后续的维护者一眼就能看懂当初为什么要这么定类型。

这个习惯帮我避开了很多线上事故，也让我在Review别人代码时，能快速指出“这里用INT会溢出”“那里用DOUBLE会丢精度”。数据类型的本质不是一堆语法规则，而是一张你和未来之间的契约——它决定了这张表能陪你走多远，也决定了当数据量上来之后，MySQL是替你扛住压力，还是第一个崩掉。