为何WordPress用bigint(20)？mediumint(1)与mediumint(20)对比分析

我注意到WordPress的wp_options、wp_users、wp_comments表使用了bigint(20)类型的字段，于是创建了以下两个测试表做验证，插入数据后得到了完全相同的结果：

CREATE TABLE `prueba` (
  `id` mediumint(9) UNSIGNED NOT NULL,
  `n1` mediumint(1) UNSIGNED NOT NULL,
  `n2` mediumint(1) UNSIGNED NOT NULL
) ENGINE=MyISAM DEFAULT CHARSET=utf8;

ALTER TABLE `prueba`
  ADD PRIMARY KEY (`id`);
ALTER TABLE `prueba`
  MODIFY `id` mediumint(9) NOT NULL AUTO_INCREMENT, AUTO_INCREMENT=4;
COMMIT;


CREATE TABLE `prueba2` (
  `id` mediumint(20) NOT NULL,
  `n1` mediumint(20) UNSIGNED NOT NULL,
  `n2` mediumint(20) UNSIGNED NOT NULL
) ENGINE=MyISAM DEFAULT CHARSET=utf8;

ALTER TABLE `prueba2`
  ADD PRIMARY KEY (`id`);
ALTER TABLE `prueba2`
  MODIFY `id` mediumint(9) NOT NULL AUTO_INCREMENT, AUTO_INCREMENT=4;
COMMIT;

INSERT INTO `prueba` VALUES (NULL, 1, 1);
INSERT INTO `prueba` VALUES (NULL, 16777215, 16777215);
INSERT INTO `prueba2` VALUES (NULL, 1, 1);
INSERT INTO `prueba2` VALUES (NULL, 16777215, 16777215);

由此产生的疑问，逐一解答如下：

1. mediumint(20)会占用更多磁盘空间吗？ #

不会。MySQL中整数类型后面的括号数字是显示宽度，仅用于控制查询结果的显示格式（比如开启ZEROFILL时，会用0补全到指定宽度），和实际存储的字节数、取值范围完全无关。

不管是mediumint(1)还是mediumint(20)，存储时都固定占用3字节：无符号的取值范围是0_{16777215，有符号是-8388608}8388607，两者的磁盘占用完全一致。

2. mediumint(1)的查询速度更快吗？ #

不会。因为两种类型的存储结构、数据大小完全相同，查询时的IO开销、索引匹配效率没有任何区别，所以查询速度是一样的，不存在谁更快的情况。

3. 作为id字段，mediumint(1)与mediumint(20)哪个更优？ #

从功能上看，两者没有任何区别，但从代码可读性和规范角度：

• 建议直接写mediumint不指定显示宽度，或者写mediumint(9)（对应无符号mediumint的最大显示位数），因为显示宽度本身没有实际功能，只是个提示信息。
• 如果非要在1和20里选，选哪个都不影响性能，但mediumint(20)完全没有意义——因为mediumint最多只能存8位无符号整数，20位的显示宽度完全超出了它的取值范围，反而会让其他开发者误解这个字段能存更大的数。

另外补充：WordPress选择bigint(20)是因为bigint存储占用8字节，取值范围极大（无符号0~18446744073709551615），能支撑超大规模站点的id增长需求；而mediumint的范围仅到百万级，对于用户量极大的站点可能会不够用，这是扩展性层面的考量。

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