MySQL核心数据类型详解：从底层存储到企业级选型指南

在高并发与海量数据的业务场景下，精准选择 MySQL 数据类型不仅是节省磁盘与内存开销的基础，更是提升 B+ 树索引效率与极致查询性能的基石。

一、 数值类型 (Numeric Types)：精准与空间的博弈

1. 整型家族：按需分配，拒绝空间浪费

在设计表结构时，开发者常犯的错误是“遇事不决用 INT”。了解底层字节占用，是架构优化的第一步：

架构师提炼：什么是 UNSIGNED？
UNSIGNED 即无符号属性。加上该关键字后，该字段将不再支持负数，底层的符号位被释放用于存储数据，从而使正数的最大取值范围直接翻倍。例如 TINYINT UNSIGNED 的上限从 127 提升到了 255。对于自增 ID 或绝对不会出现负数的物理量（如身高、库存），强烈建议加上 UNSIGNED。

2. 浮点与定点型：精度丢失的万恶之源

• FLOAT (4 Bytes) / DOUBLE (8 Bytes)：浮点数，采用 IEEE 754 标准存储。核心缺陷是精度丢失。它们存储的是近似值，在进行等值比较（=）或数学运算时极易出现诡异的 Bug（例如 0.1 + 0.2 ≠ 0.3）。
• DECIMAL (M, D)：定点数。底层实际上是以字符串的形式将数字分段存储，彻底解决了精度溢出和丢失的问题。

⚠️ 企业级避坑绝对红线：
在任何涉及金额、财务计算、交易流水等需要绝对精度的场景下，必须且只能使用 DECIMAL（例如 DECIMAL(10,2)），绝对不能使用 FLOAT 或 DOUBLE。否则在账目对账时出现的哪怕一分钱的误差，都会引发严重的生产事故。

二、 字符串类型 (String Types)：定长与变长的性能抉择

1. 核心对比：CHAR 与 VARCHAR

2. TEXT 与 BLOB：大对象的性能黑洞

• TEXT：用于存储极长的文本字符串（如文章正文、富文本内容）。
• BLOB：用于存储二进制大数据（如图片、音频流）。

架构师避坑指南：为什么绝对不建议在 TEXT/BLOB 上建普通索引？
在 InnoDB 引擎中，单个数据页大小默认为 16KB。由于 TEXT/BLOB 数据极其庞大，通常采用行溢出存储（Off-page Storage），即数据页中只存储一个 20 字节的指针，真实数据存放在独立的溢出页中。
如果在这些字段上建立索引，会导致 B+ 树的非叶子节点变得异常巨大，单个数据页能容纳的索引项急剧减少，树的层级变高，最终引发灾难性的磁盘 I/O 放大。如果非要搜索文本，请使用**前缀索引（Prefix Index）**或直接引入 ElasticSearch。

三、 日期和时间类型 (Date and Time)：时区与未来的碰撞

以下是 MySQL 常见的日期时间类型全景图：

架构师重点解析：DATETIME 与 TIMESTAMP 的终极对决

这两者在外观上完全一致，但底层逻辑截然不同：

1. 时区感知能力（核心区别）：
   • DATETIME 是“绝对时间”。你存入 2024-01-01 12:00:00，无论数据库时区怎么变，读出来的永远是这个字符串，它无视时区。
   • TIMESTAMP 是“相对时间”。它在存储时会自动将当前时间转换为 UTC（世界标准时间）保存，在查询时再将 UTC 转换回当前会话的时区进行展示。它强依赖时区。
2. 2038 年虫问题（Y2K38 危机）：
   • TIMESTAMP 底层采用 4 字节的整型时间戳存储，其最大计数值将在 UTC 时间 2038年1月19日凌晨3点14分07秒 发生整型溢出。这意味着如果你的系统寿命预期超过 2038 年，使用 TIMESTAMP 存储未来时间将会直接报错。

实际项目选型推荐：

• 国内纯本土项目：直接无脑推荐使用 DATETIME。没有跨时区换算烦恼，且彻底规避 2038 问题（在 MySQL 5.6+ 中，DATETIME 甚至优化到了 5 个字节）。
• 全球化出海项目：推荐使用 BIGINT 来直接存储毫秒级 Unix 时间戳，在代码应用层（如 Java8 的 Instant）进行时区格式化渲染。这既解决了跨国用户的时区一致性问题，又彻底绕开了 2038 年虫的物理限制。