MySQL中DOUBLE(n, 0)与BIGINT(n)数据类型有何差异？该如何选用？

嘿，这两个问题问得很实在，我来给你详细拆解清楚：

1. DOUBLE(n, 0)与BIGINT(n)的核心差异 #

这俩看起来都是存“整数”，但本质上是完全不同的类型，差异主要体现在这几个方面：

• 存储机制与精度：
  • BIGINT是整数类型，固定占用8字节，能精确存储范围在 -9223372036854775808 到 9223372036854775807 之间的所有整数，没有精度损失。
  • DOUBLE(n, 0)是浮点类型，同样占8字节，但遵循IEEE 754标准存储。哪怕指定了0位小数，它本质还是浮点数——当存储的整数超过2^53（约9007199254740992）时，会无法精确表示，比如9007199254740993存进去再读出来可能变成9007199254740992，出现精度丢失。
• 类型约束与数据验证：
  • BIGINT只能接收整数，如果你试图插入带小数的数值，MySQL会直接报错（严格模式下），能严格保证数据的整数特性。
  • DOUBLE(n, 0)会自动对小数进行四舍五入，比如插入123.6会被转成124存储，这可能不符合你“只存整数”的预期，而且它本身不限制必须插入整数。
• n的含义完全不同：
  • BIGINT(n)里的n只是显示宽度，不影响实际存储的数值范围，比如BIGINT(10)和BIGINT(20)存的数值范围完全一样，只是查询时显示的位数可能不同（现在很多客户端已经忽略这个设置了）。
  • DOUBLE(n, 0)里的n是总位数限制，比如DOUBLE(18, 0)最多只能存储18位数字的整数，超过这个长度会报错或被截断。
• 性能与索引效率：
  • 整数类型的BIGINT在排序、比较、索引查询时性能更优，因为浮点类型的比较需要处理精度问题，可能出现100.0和100看似相等但实际存储值不同的情况，导致查询结果不符合预期，同时索引的效率也会比整数类型低。

2. 数据无小数时，是否有理由选DOUBLE(n, 0)？ #

老实说，绝大多数情况下没有必要，BIGINT在精度、性能、数据约束上都更适合存无小数的整数。但也存在极少数极端场景可能会考虑：

• 需要存储超过BIGINT范围的“近似整数”：如果你的数值超过9e18（BIGINT的最大值），且不需要绝对精确（比如某些统计估算值），可以用DOUBLE(n, 0)——但要注意，超过2^53的整数已经无法精确存储了，这种场景其实更推荐用DECIMAL类型来存精确的大整数，或者用字符串（如果不需要数值运算的话）。
• 旧系统兼容需求：如果你的项目是基于已有系统迭代，旧系统已经广泛使用DOUBLE(n, 0)存储整数，为了避免大规模修改代码和数据结构，可能会继续沿用，但这是妥协方案，不是最优选择。
• 统一数值类型的简化处理：如果你的应用中所有数值都用DOUBLE处理，不想额外区分整数和浮点类型，可能会这么做，但这会牺牲精度和性能，得不偿失。

总的来说，只要数据在BIGINT的范围内，且需要精确存储，优先选BIGINT就对了。

内容的提问来源于stack exchange，提问作者Jon Lorusso