我已经使用SQL大约2年了，而且一直在我的脑海里。
最佳做法是将列的长度分配给您 预期
SQL需要一个特定的行作为主键，但它也是A_i字段的最佳实践......但是分配它的长度是多少？如果留空，则默认为 11 ，表示 999,999,999
这看起来很好，但是最佳做法也表明从来没有从数据库中清除任何内容;只需附加一个0或1表示已删除，这是为了存档/恢复目的..也可用于审核用户想要清除的内容..
以此为例：
我有一个网站已存在多年，遵循最佳做法，不删除数据库中的任何内容;我的数据库/网站流量很大，每天都有大量的独特用户/访问者。
现在，如果我将SQL默认长度保留为11，如果我的表达到最大长度然后另一个用户决定注册会发生什么？它会抛出错误而不会继续，这会给新用户带来少量的停机时间，因为数据库管理员必须登录到SQL并更改长度。这不是很费力，但它是在早期发展过程中可以避免的努力。
我做什么，在创建一张桌子的时候会给出 255 的长度，在我的脑海里，有些东西告诉我'这不是好习惯'，但它避免了很小的可能性上面的例子。
与没有指定长度的text字段进行比较时，为什么在A_I字段方面不能相同。
不要误解我的意思，我完全理解可用的数据类型。
我已经通过谷歌和SO进行了大量研究，但结果指出了有关改变表格以增加当前长度的问题。这不是我要求的。
总体：
总的来说，我想问的是什么; A_I字段的理想长度是多少？如果最大限度地延长错误并且还记住最佳实践，那么最大限度地减少错误被抛出的微小风险。
答案 0 :(得分：4)
原因很简单，
作为主键，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 :(得分：1)
分析您的应用程序或系统。估计每天会有多少用户注册？每年？一旦你知道这一点，然后决定你想要的“安全” - 就你希望系统运行多少年而不需要修改它。说100年就足够了......所以，将年度用户注册的预期数量乘以100，并确保PK足够大，以配合这么多的值。