问128位整数的MySQL数据类型

EN

我不知道存储它的最佳方法是什么--但至少有一个比使用varchar(39) (如果需要签名的话使用varchar(40) )更好的选择，而是使用decimal(39,0)。来自mysql文档：

不动点(精确值)类型十进制和数值类型存储精确的数字数据值.当保持精确的精度(例如货币数据)时，使用这些类型。在MySQL中，数字被实现为十进制，因此以下关于十进制的注释同样适用于数字。MySQL 5.1以二进制格式存储十进制值。在MySQL 5.0.3之前，它们被存储为字符串。见第11.18节“精确数学”。在十进制列声明中，可以(而且通常是)指定精度和刻度；例如:本例中的工资小数点(5，2)，5是精度，2是刻度。精度表示为值存储的有效数字数，而刻度表示小数点之后可以存储的数字数。标准SQL要求十进制(5，2)能够用五位数和两个小数存储任何值，因此可以存储在工资列中的值从-999.99到999.99不等。在标准SQL中，语法十进制(M)相当于十进制(M，0)。类似地，语法十进制等价于十进制(M，0)，其中允许实现决定M. MySQL的值，它支持这两种不同形式的十进制语法。默认值M为10。如果小数位数为0，则小数值不包含小数点或小数部分。小数点的最大位数为65，但给定小数列的实际范围可受给定列的精度或比例的限制。当指定小数点后面的数字超过指定刻度所允许的值时，该值将转换为该小数位数。(精确的行为是特定于操作系统的，但通常效果是截断到允许的位数。)

它是打包存储的，所以它占用的空间比varchar (18个字节，如果我的数学做得对)要小，我希望您能够直接对它进行计算，但是我从来没有试过用这么大的一个数字来看看会发生什么。

我发现自己在问这个问题，从我读到的所有文章中，我从来没有发现过任何性能比较。这是我的尝试。

我创建了以下表，其中填充了来自100个随机网络的2,000,000个随机ip地址。

CREATE TABLE ipv6_address_binary (
    id SERIAL NOT NULL AUTO_INCREMENT PRIMARY KEY,
    addr BINARY(16) NOT NULL UNIQUE
);

CREATE TABLE ipv6_address_twobigints (
    id SERIAL NOT NULL AUTO_INCREMENT PRIMARY KEY,
    haddr BIGINT UNSIGNED NOT NULL,
    laddr BIGINT UNSIGNED NOT NULL,
    UNIQUE uidx (haddr, laddr)
);

CREATE TABLE ipv6_address_decimal (
    id SERIAL NOT NULL AUTO_INCREMENT PRIMARY KEY,
    addr DECIMAL(39,0) NOT NULL UNIQUE
);

然后选择每个网络的所有ip地址并记录响应时间。二进制表的平均响应时间约为1秒，而二进制表的响应时间约为百分之一秒。

以下是查询。

注意: X_高/低是X中最重要/最不重要的64位，当NETMASK_LOW为0时，省略和条件，因为它总是产生true。对表现影响不大。

SELECT COUNT(*) FROM ipv6_address_twobigints
WHERE haddr & NETMASK_HIGH = NETWORK_HIGH
AND laddr & NETMASK_LOW = NETWORK_LOW

SELECT COUNT(*) FROM ipv6_address_binary
WHERE addr >= NETWORK
AND addr <= BROADCAST

SELECT COUNT(*) FROM ipv6_address_decimal
WHERE addr >= NETWORK
AND addr <= BROADCAST

平均响应时间：

BINARY_InnoDB  0.0119529819489
BINARY_MyISAM  0.0139244818687
DECIMAL_InnoDB 0.017379629612
DECIMAL_MyISAM 0.0179929423332
BIGINT_InnoDB  0.782350552082
BIGINT_MyISAM  1.07809265852

我认为唯一的选择是将其存储在varchar(39)字段中。