Algunos puntos:
Parece que solo está usando lo que actualmente es único en la tabla y lo está convirtiendo en una clave principal. Eso funciona. Y las claves naturales tienen algunas ventajas cuando se trata de consultas debido a la localidad. (Los datos de cada usuario se almacenan en la misma área). Y debido a que la tabla está agrupada por esa clave, lo que elimina las búsquedas de datos si está buscando por las columnas en el primario.
-
Pero usar una clave primaria natural como la que eligió también tiene desventajas para el rendimiento.
-
El uso de una clave principal muy grande hará que todos los demás índices sean muy grandes en innodb porque la clave principal se incluye en cada valor de índice.
-
El uso de una clave principal natural no es tan rápido como una clave sustituta para INSERTAR porque, además de ser más grande, no puede insertarse al final de la tabla cada vez. Tiene que insertarse en la sección para ese usuario y publicar, etc.
-
Además, si está buscando por tiempo, lo más probable es que busque en toda la tabla con una clave natural, a menos que el tiempo sea su primera columna. Las claves sustitutas tienden a ser locales para el tiempo y, a menudo, pueden ser adecuadas para algunas consultas.
-
Usar una clave natural como la suya como clave principal también puede ser molesto. ¿Qué pasa si quieres referirte a un voto en particular? Necesitas algunos campos. También es un poco difícil de usar con muchos ORM.
Aquí está la respuesta
Crearía su propia clave sustituta y la usaría como clave principal en lugar de confiar en la clave principal interna de innodb porque podrá usarla para actualizaciones y búsquedas.
ALTER TABLE tbl_rate
ADD id INT UNSIGNED NOT NULL AUTO_INCREMENT,
ADD PRIMARY KEY(id);
Pero, si crea una clave principal sustituta, también haría que su clave sea ÚNICA. Mismo costo pero impone corrección.
ALTER TABLE tbl_rate
ADD UNIQUE ( user_id, post_id, type );
