Como de costume - depende.

Em primeiro lugar, há um número máximo de colunas que o MySQL pode suporte , e você realmente não quer chegar lá.

Em segundo lugar, há um impacto no desempenho ao inserir ou atualizar se você tiver muitas colunas com um índice (embora eu não tenha certeza se isso importa no hardware moderno).

Em terceiro lugar, tabelas grandes costumam ser um depósito de lixo para todos os dados que parecem relacionados à entidade principal; isso rapidamente torna o design pouco claro. Por exemplo, o design que você apresenta mostra 3 campos diferentes do tipo "status" (status, is_admin e fb_account_verified) - Suspeito que haja alguma lógica de negócios que deva vinculá-los (um administrador deve ser um usuário verificado, por exemplo), mas seu design não suporta isso.

Isso pode ou não ser um problema - é mais uma questão conceitual de arquitetura/design do que uma coisa de desempenho/será que funcionará. No entanto, nesses casos, você pode considerar a criação de tabelas para refletir as informações relacionadas sobre a conta, mesmo que ela não tenha um relacionamento x-para-muitos. Portanto, você pode criar "user_profile", "user_credentials", "user_fb", "user_activity", todos vinculados por user_id. Isso o torna mais organizado e, se você precisar adicionar mais campos relacionados ao Facebook, eles não ficarão pendurados no extremidade da mesa. No entanto, isso não tornará seu banco de dados mais rápido ou mais escalável. O custo das junções provavelmente será insignificante.

Faça o que fizer, a opção 2 - serializar "campos raramente usados" em um único campo de texto - é uma péssima ideia. Você não pode validar os dados (portanto, as datas podem ser inválidas, os números podem ser texto, não nulos podem estar faltando) e qualquer uso em uma cláusula "onde" se torna muito lento.

Uma alternativa popular são as lojas "Entidade/Atributo/Valor" ou "Chave/Valor". Esta solução tem alguns benefícios - você pode armazenar seus dados em um banco de dados relacional mesmo que seu esquema mude ou seja desconhecido em tempo de design. No entanto, eles também têm desvantagens:é difícil validar os dados no nível do banco de dados (tipo de dados e nulidade), é difícil fazer links significativos para outras tabelas usando relacionamentos de chave estrangeira e consultar os dados pode se tornar muito complicado - imagine encontrar todos registros onde o status é 1 e o facebook_id é nulo e a data de registro é maior que ontem.

Dado que você parece conhecer o esquema de seus dados, eu diria que "chave/valor" não é uma boa escolha.