Alguns pontos:
Parece que você está apenas usando o que é atualmente único na tabela e tornando-o uma chave primária. Isso funciona. E as chaves naturais têm algumas vantagens quando se trata de consultar por causa da localidade. (Os dados de cada usuário são armazenados na mesma área). E porque a tabela é agrupada por essa chave, o que elimina pesquisas nos dados se você estiver pesquisando pelas colunas no primário.
-
Mas, usar uma chave primária natural como você escolheu também tem desvantagens para o desempenho.
-
Usar uma chave primária muito grande tornará todos os outros índices muito grandes no innodb porque a chave primária está incluída em cada valor de índice.
-
Usar uma chave primária natural não é tão rápido quanto uma chave substituta para INSERT porque, além de ser maior, ela não pode simplesmente inserir no final da tabela a cada vez. Tem que inserir na seção para esse usuário e postar etc.
-
Além disso, se você estiver pesquisando por tempo, provavelmente estará procurando por toda a tabela com uma chave natural, a menos que o tempo seja sua primeira coluna. as chaves substitutas tendem a ser locais por hora e muitas vezes podem ser adequadas para algumas consultas.
-
Usar uma chave natural como a sua como chave primária também pode ser irritante. E se você quiser se referir a um voto específico? Você precisa de alguns campos. Também é um pouco difícil de usar com muitos ORMs.
Aqui está a resposta
Eu criaria sua própria chave substituta e a usaria como chave primária em vez de confiar na chave primária interna do innodb porque você poderá usá-la para atualizações e pesquisas.
ALTER TABLE tbl_rate
ADD id INT UNSIGNED NOT NULL AUTO_INCREMENT,
ADD PRIMARY KEY(id);
Mas, se você criar uma chave primária substituta, eu também tornaria sua chave ÚNICA. Mesmo custo, mas reforça a exatidão.
ALTER TABLE tbl_rate
ADD UNIQUE ( user_id, post_id, type );
