像往常一样-这取决于。

首先，MySQL可以支持的最大列数是您真正不想要的。

其次，如果您有很多带有索引的列，则在插入或更新时会对性能产生影响（尽管我不确定这在现代硬件上是否很重要）。

第三，大表通常是似乎与核心实体有关的所有数据的转储场。这很快使设计不清楚。例如，您呈现的设计显示了3个不同的“状态”类型字段（状态，is_admin和fb_account_verified）-我怀疑应该将某些业务逻辑链接在一起（例如，管理员必须是经过验证的用户），但是您的设计不支持这一点。

这可能是问题，也可能不是问题-
与其说是性能/是否可行，不如说是概念，体系结构/设计问题。但是，在这种情况下，即使它没有多对多关系，您也可以考虑创建表以反映有关该帐户的相关信息。因此，您可以创建“
user_profile”，“ user_credentials”，“ user_fb”，“
user_activity”，并通过user_id进行链接。这使其变得更整洁，并且如果您必须添加更多与Facebook相关的字段，则它们不会在表的末尾悬垂。但是，它不会使您的数据库更快或更可扩展。联接的成本可能微不足道。

无论您做什么，选项2（将“很少使用的字段”序列化为单个文本字段）都是一个糟糕的主意。您无法验证数据（因此日期可能无效，数字可能是文本，可能会丢失非null），并且在“
where”子句中的任何使用都变得非常慢。

流行的替代方法是“实体/属性/值”或“键/值”存储。此解决方案有一些好处-
即使架构发生更改或在设计时未知，您也可以将数据存储在关系数据库中。但是，它们也有缺点：很难在数据库级别验证数据（数据类型和可空性），很难使用外键关系与其他表进行有意义的链接，并且查询数据可能会变得非常复杂-
想象找到所有记录状态为1且facebook_id为null且注册日期大于昨天的记录。

考虑到您似乎了解数据的架构，我认为“键/值”不是一个好选择。