いつものように-それは異なります。
まず、MySQLが使用できる最大列数がありますサポート 、そしてあなたは本当にそこに行きたくないのです。
次に、インデックス付きの列が多数ある場合、挿入または更新時にパフォーマンスに影響があります（ただし、これが最新のハードウェアで重要かどうかはわかりません）。
第3に、大きなテーブルは、コアエンティティに関連していると思われるすべてのデータのダンプグラウンドになることがよくあります。これにより、設計が急速に不明確になります。たとえば、提示するデザインには3つの異なる「ステータス」タイプのフィールド（status、is_admin、fb_account_verified）が表示されます。これらをリンクするビジネスロジックがあると思います（たとえば、管理者は確認済みのユーザーである必要があります）。デザインはそれをサポートしていません。
これは問題である場合とそうでない場合があります。パフォーマンスよりも概念的なアーキテクチャ/設計の問題であり、機能しますか。ただし、このような場合は、アカウントにx対多の関係がない場合でも、アカウントに関連する情報を反映するテーブルを作成することを検討してください。したがって、「user_profile」、「user_credentials」、「user_fb」、「user_activity」を作成し、すべてuser_idでリンクすることができます。これにより、見栄えが良くなり、Facebook関連のフィールドをさらに追加する必要がある場合でも、テーブルの終わり。ただし、データベースの高速化や拡張性は向上しません。結合のコストはごくわずかである可能性があります。
何をするにしても、オプション2-「めったに使用されないフィールド」を単一のテキストフィールドにシリアル化する-はひどい考えです。データを検証できず（日付が無効である可能性があり、数値がテキストである可能性があり、null以外が欠落している可能性があります）、「where」句での使用は非常に遅くなります。
人気のある代替手段は、「エンティティ/属性/値」または「キー/値」ストアです。このソリューションにはいくつかの利点があります。スキーマが変更されたり、設計時に不明な場合でも、データをリレーショナルデータベースに保存できます。ただし、欠点もあります。データベースレベルでデータを検証するのが難しく（データ型とnull可能性）、外部キーの関係を使用して他のテーブルに意味のあるリンクを作成するのが難しく、データのクエリが非常に複雑になる可能性があります。すべてを見つけることを想像してください。ステータスが1で、facebook_idがnullで、登録日が昨日よりも大きい場合を記録します。
データのスキーマを知っているように見えることを考えると、「キー/値」は適切な選択ではないと思います。