mysql - 为什么要为自增 ID 指定长度

Question

我已经使用 SQL 工作大约 2 年了，它一直在我的脑海中。

Best practices say assign the length of the column to what you are expecting

SQL 需要一个特定的行作为主键，但它也是 A_i 字段的最佳实践......但是分配它的长度是多少？如果留空，则默认为 11，表示 999,999,999

这看起来不错，但最佳实践还声明永远不要从数据库中实际清除任何内容；只需附加一个 0 或 1 来表示已删除，这是为了存档/恢复目的。也可用于审核用户想要清除的内容。

举个例子:

我有一个存在多年的网站，遵循不从数据库中删除任何内容的最佳实践；我的数据库/网站流量非常大，每天有大量独立用户/访问者。

现在，如果我保留 SQL 默认长度 11，如果我的表达到最大长度然后另一个用户决定注册，会发生什么情况？它会抛出一个错误并且不会继续，这会给新用户带来少量的停机时间，原因是数据库管理员将不得不登录到 SQL 并更改长度。这并不费力，但它是在早期开发过程中可以避免的努力..

---

我所做的是，在创建表格时给出 255 的长度，在我的脑海中，有些东西告诉我“这不是好的做法”，但它避免了非常渺茫的可能性上面提到的例子。

与没有指定长度的 text 字段相比，为什么 A_I 字段不能相同。

不要误会我的意思，我完全理解可用的数据类型。

---

我通过 google 和 SO 进行了大量研究，但结果指出了有关更改表格以增加当前长度的问题。这不是我要的。

---

总体:

总的来说，我想问的是什么； A_I 字段的理想长度是多少？最大限度地减少在超出长度的情况下抛出错误的微小风险，同时牢记最佳实践。

Answer 1

原因很简单，
作为主键，ID 应该正好符合您的期望。
如果您指定一个 varchar，缺点是索引的大小更大，
这可能会降低读写性能。

int(11) .. 最多不存储 99,999,999,999。
它最多只能存储 2,147,483,647。

如果将其设置为无符号，
那么它可以允许 4,294,967,295 条记录(40 亿!)

Facebook 的用户刚刚超过 10 亿!
所以，我看不出任何人都能很快拥有 4 倍大的用户群......

本文对一些最佳实践进行了很好的解释:

http://net.tutsplus.com/tutorials/other/top-20-mysql-best-practices/

1. 越小的列越快
2. integer是定长的，varchar不是定长的
3. 索引并使用相同的列类型进行联接