MySQL中的十进制VS Int？

Question

decimal(10,0) unsigned类型和int(10) unsigned类型之间是否存在性能差异？

Answer 1

它可能取决于您使用的MySQL版本.看到这里.

在MySQL 5.0.3之前,DECIMAL类型存储为字符串,通常会更慢.但是,由于MySQL 5.0.3 DECIMAL类型以二进制格式存储,因此上面的DECIMAL大小,性能可能没有太大差异.

主要的性能问题是不同类型占用的空间量(DECIMAL较慢).使用MySQL 5.0.3+这似乎不是一个问题,但是如果您将作为查询的一部分对值执行数值计算,则可能存在一些性能差异.这可能值得测试,因为文档中没有迹象表明我可以看到.

编辑: 关于int(10) unsigned,我把面值作为4字节int.但是,它的最大值为4294967295,严格地说不能提供与a相同的数字范围DECIMAL(10,0) unsigned .

正如@Unreason指出的那样,您需要使用a bigint来覆盖全部10位数字,将大小推广到8个字节.

一个常见的错误是,在MySQL中指定数字列类型时,人们通常认为括号中的数字会影响它们可以存储的数字的大小.它没有.数字范围完全基于列类型以及是有符号还是无符号.括号中的数字用于显示结果,不会影响列中存储的值.除非您同时ZEROFILL在列上指定选项,否则它也不会影响结果的显示.

Answer 2

根据mysql数据存储，您的小数将需要

DECIMAL(10,0)：4 个字节表示 9 位数字，1 个字节表示剩余的第 10 位数字，因此总共 5 个字节（假设我对文档的阅读是正确的）。

INT(10)：需要8 个字节的 BIGINT。

不同之处在于小数是压缩的，并且对此类数据类型的某些操作可能比在直接映射到机器表示的数字的普通 INT 类型上慢。

我仍然会做你自己的测试来确认上述推理。

编辑：我注意到我没有详细说明明显的一点 - 假设上述逻辑是合理的，所需的大小差异是 BIGINT 变体所需的空间多 60%。

然而，这并不直接转化为惩罚，因为数据通常不是逐字节写入的。在选择/更新多行的情况下，您应该看到性能损失/提高，但在选择/更新少量行的情况下，文件系统将从磁盘中获取块，这通常会获取/写入多列.
索引的大小（和速度）可能会受到更直接的影响。然而，关于填料如何影响各种操作的问题仍然悬而未决。