Facebook的用户ID上升到2 ^ 32 ..据我统计它为4294967296。
mySQL的unsigned int的范围是0到4294967295（这是1短 - 或者我的数学错误） 其无符号大int的范围是0到18446744073709551615
int = 4个字节，bigint = 8个字节
OR
我是否将其存储为字符串？
varchar（10）=？字节
它将如何影响效率，我听说mysql句柄的数字远胜于字符串（性能明智）。所以你们推荐什么
答案 0 :(得分：86)
因为Facebook会分配ID而不是您，所以必须使用BIGINT。
Facebook没有按顺序分配ID，我怀疑他们有一些分配号码的制度。
我最近修正了这个错误，所以这是一个真正的问题。
我会把它变成UNSIGNED，因为它就是它。
我不使用字符串。这使比较变得痛苦，你的索引比他们需要的更笨拙。
答案 1 :(得分：4)
您不能再使用INT了。昨晚我有两个用户id最大化了INT（10）。
答案 2 :(得分：4)
我使用bigint存储facebook id，因为它就是这样。
但在内部对于表的主键和外键，我使用smallint，因为它更小。但也因为如果bigint应该成为一个字符串（用户名而不是id来查找用户），我可以很容易地改变它。
所以我有一个看起来像这样的表：
profile
- profile_key smallint primary key
- profile_name varchar
- fb_profile_id bigint
和一个看起来像这样的
something_else
- profile_key smallint primary key
- something_else_key smallint primary key
- something_else_name varchar
我对单页的查询可能是这样的：
select profile_key, profile_name
from profile
where fb_profile_id = ?
现在我使用profile_key并在下一个查询中使用它
select something_else_key, something_else_name
from something_else
where profile_key = ?
无论如何，几乎所有请求几乎都会查询配置文件表，因此我不认为这是额外的步骤。
当然，缓存第一个查询以获得额外的性能也非常容易。
答案 3 :(得分：4)
如果您在2015年阅读此内容时facebook已将其API升级到2.0版本。他们在他们的文档中添加了一个注释，说明他们的ID将被更改并具有应用范围。因此，将来可能会有很大的可能性，他们可能会将所有ID更改为Alpha数字。
https://developers.facebook.com/docs/apps/upgrading#upgrading_v2_0_user_ids 所以我建议将类型保持为varchar并避免任何未来的迁移痛苦
答案 4 :(得分：3)
你的数学有点错误......记住，你可以用N个字节存储的最大数字是2 ^（N） - 1 ...不是2 ^（N）。有2 ^ N 个可能的数字，但是你可以存储的最大数字是1。
如果Facebook使用unsigned big int，那么你应该使用它。他们可能不会按顺序分配它们。
是的，你可以使用varchar ...但是它会慢一点（但可能没有你想的那么多）。
答案 5 :(得分：2)
将它们存储为字符串。
Facebook Graph API将ID作为字符串返回，因此如果您希望比较无需强制转换，则应使用字符串。国际海事组织胜过其他考虑因素。
答案 6 :(得分：-5)
我会坚持使用INT。它很简单，很小，很有效，如果需要，您可以随时将列更改为更大的尺寸。
供参考：
VARCHAR(n) ==> variable, up to n + 1 bytes
CHAR(n) ==> fixed, n bytes
答案 7 :(得分：-6)
除非你预计世界上超过60％的人口会注册，否则int应该这样做？