Depende
Existem muitas discussões existentes sobre as trocas entre Chaves naturais e substitutas - você precisará decidir o que funciona para você e qual é o 'padrão' dentro de sua organização.
No caso do OP, existe uma chave substituta (
int userId ) e uma chave natural (char ou varchar username ). Qualquer coluna pode ser usada como chave primária para a tabela e, de qualquer forma, você ainda poderá impor a exclusividade da outra chave. Aqui estão algumas considerações ao escolher um caminho ou outro:
O caso de usar chaves substitutas (por exemplo, UserId INT AUTO_INCREMENT)
Se você usar um substituto, (por exemplo,
UserId INT AUTO_INCREMENT ) como a chave primária, todas as tabelas que fazem referência à tabela MyUsers deve então usar UserId como a Chave Estrangeira. No entanto, você ainda pode impor a exclusividade do
username coluna por meio do uso de um índice exclusivo
adicional , por exemplo.:CREATE TABLE `MyUsers` (
`userId` int NOT NULL AUTO_INCREMENT,
`username` varchar(100) NOT NULL,
... other columns
PRIMARY KEY(`userId`),
UNIQUE KEY UQ_UserName (`username`)
De acordo com @Dagon, usando uma chave primária estreita (como um
int ) tem benefícios de desempenho e armazenamento em relação ao uso de um valor mais amplo (e de comprimento variável) como varchar . Esse benefício também afeta outras tabelas que fazem referência a MyUsers , como a chave estrangeira para userid será mais estreito (menos bytes para buscar). Outro benefício da chave inteira substituta é que o nome de usuário pode ser alterado facilmente sem afetar as tabelas que fazem referência a
MyUsers .Se o username foi usado como chave natural, e outras tabelas são acopladas a MyUsers via username , torna muito inconveniente alterar um nome de usuário (já que o relacionamento de chave estrangeira seria violado). Se a atualização de nomes de usuário for necessária em tabelas usando username como a chave estrangeira, uma técnica como ON UPDATE CASCADE
é necessário para manter a integridade dos dados. O caso de usar chaves naturais (ou seja, nome de usuário)
Uma desvantagem de usar chaves substitutas é que outras tabelas que fazem referência a
MyUsers através de uma chave substituta precisará ser JOIN ed de volta para MyUsers tabela se o Username coluna é necessária. Um dos benefícios potenciais das chaves naturais é que, se uma consulta requer apenas o Username coluna de uma tabela referenciando MyUsers , que não precisa voltar a MyUsers para recuperar o nome de usuário, o que economizará alguma sobrecarga de E/S. 
