为什么要为自动增量 ID 指定长度

Question

我已经使用 SQL 大约 2 年了，这一直是我的想法。

最佳做法是将列的长度分配给您的身份 期待

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. 整数是定长，而varchar不是定长
3. 索引并使用相同的列类型进行连接

Answer 2

分析您的应用程序或系统。估计每天有多少用户注册？每年？一旦你知道了这一点，然后决定你想要有多“安全” - 就你希望系统运行多少年而不需要修改它而言。假设 100 年就足够了...因此，将预期的年度用户注册数乘以 100，并确保 PK 足够大以容纳这么多的值。