0
310
VistasClaves foráneas vs claves compuestas en MySQL
Tengo una tabla como esta:
USER_RELATIONSHIP ---------------------- user_id follows_id 1 2 1 3 2 1 3 1Tanto user_id como follow_id son claves foráneas que apuntan a una tabla de usuarios. La tabla USER_RELATIONSHIP es bastante grande y con frecuencia verifico si existe una relación de usuario o no (por ejemplo, el usuario A sigue al usuario B).
Dado que estas claves foráneas están indexadas, ¿puede SQL encontrar una relación (dado un ID de usuario y un ID de seguimiento) en O (1)?
Si no es así, ¿es mejor condensar los dos campos anteriores en una clave compuesta indexada que codifica un ID de usuario y un ID de seguimiento y tiene la tabla USER_RELATIONSHIP como esta?
USER_RELATIONSHIP ---------------------- composite_key 298437920 219873423 918204329 9023482932 Respuestas
Responde la pregunta0
Almacenar en un índice una cadena que es el resultado de una función hash no la convierte en un índice hash.
Todavía es un índice de árbol B, y las búsquedas toman tiempo O (log n).
En MySQL, los motores de almacenamiento comunes InnoDB (el predeterminado) y MyISAM no admiten índices hash. Solo los motores de almacenamiento Memory y NDB admiten índices de tipo hash.
Consulte https://dev.mysql.com/doc/refman/8.0/en/create-index.html :
No hay forma de realizar una búsqueda O(1) en InnoDB.
No hay diferencia en la complejidad entre usar un índice de varias columnas y un índice en el resultado de cadena de una función hash.
0
No es más eficaz condensar los datos en una sola columna. Tengo bastante curiosidad por qué estás preguntando.
Si tiene un índice compuesto en (user_id, follows_id) , entonces la búsqueda es en tiempo O (log n), el registro del número de filas en la tabla. Eso es bastante pequeño para la mayoría de las mesas. Y, si la tabla es tan grande que el tiempo de búsqueda del índice es medible, entonces necesita el índice aún más.