MySQL中的十进制VS Int？

Question

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

Answer 1

这可能取决于您使用的MySQL版本。请参阅here。

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

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

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

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

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

Answer 2

根据mysql数据storage，您的小数将需要

DECIMAL（10,0）：9个数字为4个字节，剩余第10个数字为1个字节，所以总共五个字节（假设我的文档读数正确）。

INT（10）：will need BIGINT，即8个字节。

不同之处在于十进制是打包的，并且对这种数据类型的某些操作可能比直接映射到机器表示的数字的普通INT类型慢。

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

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

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

Answer 3

根据这个类似的问题，是的，可能有一个很大的性能命中，因为DECIMAL和INT的处理方式不同，并在进入CPU时进行了线程化做计算。

请参阅：Is there a performance hit using decimal data types (MySQL / Postgres)

Answer 4

我怀疑这种差异可能与表现有关。
大多数性能问题都与正确的数据库设计和索引计划相关，服务器/硬件调优则与下一级相关。