Facebook 的用户 ID 上升到 2^32 .. 据我计算，它是 4294967296。
mySQL 的 unsigned int 范围是 0 到 4294967295（短 1 - 或者我的数学是错误的） 其无符号大整数的范围是0到18446744073709551615
int = 4 字节，bigint = 8 字节
或
我是否将其存储为字符串？
varchar(10) = ?字节
它将如何影响效率，我听说mysql句柄的数字比字符串好得多（性能方面）。那么大家有什么推荐的
【问题讨论】：
因为 Facebook 分配 ID，而不是您，所以您必须使用 BIGINT。
Facebook 不会按顺序分配 ID，我怀疑他们有一些分配号码的机制。
我最近修复了这个错误，所以这是一个真正的问题。
我会把它设为 UNSIGNED，仅仅是因为它就是这样。
我会不使用字符串。这使得比较很痛苦，并且您的索引比他们需要的更笨重。
【讨论】：
你不能再使用 INT 了。昨晚我有两个用户 id 超过了 INT(10)。
【讨论】：
我使用 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 = ?
无论如何，几乎任何请求都会查询配置文件表，所以我不认为这是一个额外的步骤。
当然，缓存第一个查询以获得额外性能也很容易。
【讨论】：
如果您在 2015 年 facebook 将其 API 升级到 2.0 版本时阅读此内容。他们在文档中添加了一条注释，说明他们的 id 将被更改并具有应用范围。因此，将来他们可能会将所有 id 更改为 Alpha 数字。
https://developers.facebook.com/docs/apps/upgrading#upgrading_v2_0_user_ids 所以我建议将类型保留为 varchar 并避免任何未来的迁移痛苦
【讨论】：
您的数学有点错误...请记住，您可以存储在 N 个字节中的最大数字是 2^(N) - 1...而不是 2^(N)。有 2^N 可能的个数字，但是您可以存储的最大数字是 1 少。
如果 Facebook 使用 unsigned big int，那么您应该使用它。他们可能不会按顺序分配它们。
是的，您可以使用 varchar...但它会更慢（但可能没有您想象的那么多）。
【讨论】：
将它们存储为字符串。
Facebook Graph API 将 id 作为字符串返回，因此如果您希望无需强制转换即可进行比较，您应该使用字符串。 IMO 这胜过其他考虑。
【讨论】：
我会坚持使用 INT。这很简单，它很小，很有效，如果您需要，您可以随时将列更改为更大的尺寸。
仅供参考：
VARCHAR(n) ==> variable, up to n + 1 bytesCHAR(n) ==> fixed, n bytes
【讨论】：
除非您预计全球 60% 以上的人口会注册，否则 int 应该这样做吗？
【讨论】：