MySql的字段类型：如何选择最适合的类型

1 . 整数选择： TINYINT 存储 0 到 1 2 7 （1 个字节），SMALLINT 存储 -3 2 7 6 8 到 3 2 7 6 7 （2 个字节）。
INT 存储常规整数（4 个字节）。
BIGINT 存储非常大的数据（8 字节）。
与 INT 相比，用户特定的 TINYINT (0/1 ) 节省了 3 /4 个字节。

2 浮点选择： FLOAT 存储 6 个小数位（4 个字节）。
DOUBLE 存储小数点后 1 5 位以上的值（8 个字节）。
Finance 使用 DECIMAL(1 0,2 ) 正确计算（没有错误）。

3 .选择字符串类型： CHAR存储固定长度（例如国家代码，效率高但浪费空间）。
VARCHAR存储可变长度（仅实际长度+1 /2 字节，例如用户名）。
TEXT 存储长文本（例如文章），但查询速度较慢，因此我们建议使用 VARCHAR(5 00)。

4 选择日期和时间： TIMESTAMP 存储 UTC 时间戳（4 个字节，自动时区转换）。
DATETIME 存储固定时区日期（8 个字节）。
DATE 存储日期（3 个字节）。
TIME 存储时间（3 个字节）。

5 .枚举类型的选择： ENUM 存储固定值（状态、最多 1 0 个值、高更改成本等）。
该值可以是 VARCHAR 或相关表。

优先考虑存储效率、查询性能和一致性。
你自己掂量一下吧。

MYSQL数据库设计数据类型选择需要注意哪些地方

正确的？你提到的关于数据库中字符串存储的事情，我之前在做项目时确实遇到过陷阱...
上周一位客户问我为什么他们的系统查询速度突然变慢了。
当我检查时，我发现数据库中充满了UUID字符串。
如果您仔细想想，每个 INSERT 操作都会将一个 1 2 8 位随机字符串放入其中。
该索引必须是根。
您提到的“随机磁盘访问”是真的！结果是查询期间 CPU 出现峰值，磁盘 I/O 也会激增。

关于VARCHAR和CHAR，我自己踩的坑是2 02 2 年北京的一个电商项目，早期用VARCHAR是为了省事。
因此，数据更新频繁。
例如，用户更改了昵称，产品更改了描述。
数据库碎片直接上升到7 0%以上。
后来改用CHAR(2 0)定长，这样节省了一些空间，但是内存消耗增加了。
所以这要看具体情况，不是绝对的。

ENUM类型...我基本上不再使用它了。
2 02 1 年我在上海测试一个金融系统时，发现ENUM是用来存储状态的（比如ON/OFF）。
虽然以整数的形式存储以节省空间，但开发人员在编写代码时总是忘记添加 CASE 语句，从而出现了一些错误。
MySQL 官方建议逐步淘汰它。

最让我烦恼的是完全随机的字符串。
2 02 3 年我在上海一家商场做的一个项目中，客户坚持使用MD5 来存储设备ID。
这样一来，整个分库分表的逻辑就变得异常复杂。
你提到的“缓存错误”简直就是一场噩梦。
虽然数据量不大，但缓存命中率低至2 0%。
后来就改成时间戳+自增ID的方式就可以了。
虽然不像 UUID 那样“唯一”，但搜索性能立即恢复到正常水平。

但是您提到的 UHEX 到 UUID 转换是一个好主意。
2 02 2 年，我在深圳帮助另一家公司建设物流系统时，尝试把UUID中的横线去掉，转为BINARY(1 6 )，实际上解决了索引碎片、查找慢的问题。
即使转换过程需要添加一个功能，也比让整个系统冻结要好。

无论如何，这取决于你。
具体使用哪种类型取决于您的业务场景。
除非有非常明确的原因，否则绝对应该谨慎使用随机字符串。