建表的时候把金额存成 FLOAT，早晚有一天你会对着财务发来的对账差异骂人。这不是夸张，我见过一家做电商的小公司，订单表里 price 字段用了 FLOAT，结果促销满减算出来的总额和用户实际支付差了一分钱。就这一分钱，客服被投诉了半个月，最后 DBA 把字段改成 DECIMAL(10,2) 才消停。SQL 里的类型不是随便选的，它决定了数据怎么存、怎么算、能不能塞进去、塞进去之后会不会变形。

整数类型看着简单，坑也不少。MySQL 的 INT 有符号范围是 -21 亿到 21 亿，你拿它存用户 ID 没问题，但拿它存微博点赞数就悬了。当年 Twitter 的推文 ID 从 INT 换成 BIGINT，就是因为每秒几万条推文，32 位不够用。更隐蔽的是 INT(11) 这种写法，很多人以为括号里的数字限制长度，其实在 MySQL 里它只影响显示宽度，跟存储范围半毛钱关系没有。我见过面试官拿这个考人，答错了直接挂。

字符串类型的选择更像一场性格测试。CHAR 是固定长度，存手机号、MD5 值这种长度恒定的数据合适，查询快，但存姓名就浪费空间——你给“李雷”分配 50 个字符，剩下 48 个位置全填空格，取出来还得 TRIM 一下。VARCHAR 灵活，按实际长度存，但更新的时候如果新值比旧值长，InnoDB 可能得挪动行记录，产生碎片。所以别没事就 UPDATE 一个 VARCHAR(255) 的字段，把它从“abc”改成一篇小作文，性能会教你做人。至于 TEXT，能不用就不用，它和 VARCHAR 在内存里的处理方式不一样，排序、临时表都可能走磁盘，慢得你怀疑人生。

时间类型是另一个重灾区。DATETIME 和 TIMESTAMP 长得像，脾气完全不同。DATETIME 存的是字面量，你写 '2024-01-01 12:00:00'，它就存这个，跟时区无关。TIMESTAMP 存的是 UTC 时间戳，查询时按服务器时区转换。这意味着你把数据库从北京迁到纽约，TIMESTAMP 字段的值会“变”，DATETIME 不会。很多跨时区的系统在这上面栽过跟头。还有个细节：TIMESTAMP 范围只到 2038 年，DATETIME 能到 9999 年。你要是做长期存档系统，选哪个不用我多说。

布尔类型是个哲学问题。标准 SQL 有 BOOLEAN，但 MySQL 里它只是 TINYINT(1) 的别名。你写 TRUE，存进去是 1；写 FALSE，存进去是 0。但如果你写 2，它也不报错，照样存。所以别指望数据库帮你做布尔校验，应用层该拦还得拦。PostgreSQL 倒是老实，BOOLEAN 就是真布尔，只接受 true、false、null，塞个 2 进去直接报错。两种风格没有绝对好坏，但迁移的时候够你喝一壶。

选类型的时候，我自己的习惯是：金额一律 DECIMAL，别碰浮点；ID 用 BIGINT 起步，别省那几个字节；状态字段用 TINYINT 配注释，比 ENUM 好改；时间存 DATETIME 还是 TIMESTAMP 看业务要不要跨时区。这些选择没有标准答案，但每一个都会在未来的某次查询、某次迁移、某次对账里显现出来。类型选错，改起来可不是 ALTER TABLE 那么简单——数据可能已经变形了，你改字段类型，它未必能变回去。