Som sædvanlig - det kommer an på.
For det første er der et maksimalt antal kolonner MySQL kan support , og du ønsker ikke rigtig at komme dertil.
For det andet er der en præstationspåvirkning, når du indsætter eller opdaterer, hvis du har mange kolonner med et indeks (selvom jeg ikke er sikker på, om dette betyder noget på moderne hardware).
For det tredje er store tabeller ofte en dumpingplads for alle data, der synes relateret til kerneenheden; dette gør hurtigt designet uklart. For eksempel viser det design, du præsenterer 3 forskellige "status"-typefelter (status, is_admin og fb_account_verified) - jeg formoder, at der er en eller anden forretningslogik, der burde forbinde dem sammen (en administrator skal f.eks. være en verificeret bruger), men din design understøtter det ikke.
Dette kan være eller ikke være et problem - det er mere et konceptuelt, arkitektur/design spørgsmål end en præstation/vil det virke ting. I sådanne tilfælde kan du dog overveje at oprette tabeller for at afspejle de relaterede oplysninger om kontoen, selvom den ikke har en x-til-mange-relation. Så du kan oprette "user_profile", "user_credentials", "user_fb", "user_activity", alle sammenkædet af user_id. Dette gør det pænere, og hvis du skal tilføje flere facebook-relaterede felter, hænger de ikke ved ende af bordet. Det vil dog ikke gøre din database hurtigere eller mere skalerbar. Omkostningerne ved sammenføjningerne vil sandsynligvis være ubetydelige.
Uanset hvad du gør, er mulighed 2 - at serialisere "sjældent brugte felter" til et enkelt tekstfelt - en frygtelig idé. Du kan ikke validere dataene (så datoer kan være ugyldige, tal kan være tekst, ikke-nuller kan mangle), og enhver brug i en "hvor"-sætning bliver meget langsom.
Et populært alternativ er "Entity/Attribute/Value" eller "Key/Value" butikker. Denne løsning har nogle fordele - du kan gemme dine data i en relationsdatabase, selvom dit skema ændres eller er ukendt på designtidspunktet. Men de har også ulemper:det er svært at validere dataene på databaseniveau (datatype og nullabilitet), det er svært at lave meningsfulde links til andre tabeller ved hjælp af fremmednøglerelationer, og det kan blive meget kompliceret at forespørge dataene - forestil dig at finde alle poster, hvor status er 1 og facebook_id er null og registreringsdatoen er større end i går.
I betragtning af at du tilsyneladende kender skemaet for dine data, vil jeg sige, at "nøgle/værdi" ikke er et godt valg.