Som vanligt - det beror på.
För det första finns det ett högsta antal kolumner som MySQL kan support , och du vill inte riktigt komma dit.
För det andra är det en prestandapåverkan när du infogar eller uppdaterar om du har många kolumner med ett index (även om jag inte är säker på om detta spelar någon roll på modern hårdvara).
För det tredje är stora tabeller ofta en dumpningsplats för all data som verkar relaterad till kärnenheten; detta gör snabbt designen otydlig. Till exempel visar designen du presenterar tre olika fält av "status"-typ (status, is_admin och fb_account_verified) - jag misstänker att det finns någon affärslogik som borde länka samman dessa (en administratör måste till exempel vara en verifierad användare), men din design stöder inte det.
Detta kan eller kanske inte är ett problem - det är mer en konceptuell, arkitektur/designfråga än en prestanda/kommer det att fungera. Men i sådana fall kan du överväga att skapa tabeller för att återspegla den relaterade informationen om kontot, även om det inte har en x-till-många-relation. Så du kan skapa "user_profile", "user_credentials", "user_fb", "user_activity", alla länkade av user_id. Detta gör det snyggare, och om du måste lägga till fler Facebook-relaterade fält, kommer de inte att dingla vid slutet av bordet. Det kommer dock inte att göra din databas snabbare eller mer skalbar. Kostnaden för sammanfogningarna är sannolikt försumbar.
Vad du än gör är alternativ 2 - att serialisera "sällan använda fält" till ett enda textfält - en hemsk idé. Du kan inte validera data (så att datum kan vara ogiltiga, siffror kan vara text, not-null kan saknas), och all användning i en "where"-sats blir mycket långsam.
Ett populärt alternativ är "Entity/Attribute/Value" eller "Key/Value"-butiker. Denna lösning har vissa fördelar - du kan lagra dina data i en relationsdatabas även om ditt schema ändras eller är okänt vid designtillfället. Men de har också nackdelar:det är svårt att validera data på databasnivå (datatyp och nollbarhet), det är svårt att skapa meningsfulla länkar till andra tabeller med hjälp av främmande nyckelrelationer, och det kan bli mycket komplicerat att söka efter data – tänk dig att hitta alla poster där statusen är 1 och facebook_id är null och registreringsdatumet är längre än igår.
Med tanke på att du verkar känna till schemat för dina data, skulle jag säga att "nyckel/värde" inte är ett bra val.