2010-04-11 20 views
14

Estoy compilando la aplicación Ruby on Rails 2.3.5. Por defecto, Ruby on Rails no proporciona contraseñas de claves foráneas, así que tengo que hacerlo manualmente. Me preguntaba si la introducción de claves externas reduce el rendimiento de las consultas en la base de datos lo suficiente como para que no valga la pena hacerlo. El rendimiento en este caso es mi primera prioridad ya que puedo verificar la coherencia de los datos con el código. ¿Cuál es tu recomendación en general? ¿Recomiendas usar claves extranjeras? y ¿cómo sugieres que debería medir esto?¿La introducción de claves externas a MySQL reduce el rendimiento?

+0

claves externas realmente tiene un efecto positivo en el rendimiento teniendo en cuenta su efecto en las consultas de selección entre tablas mediante combinaciones. No estoy seguro de si tiene un efecto negativo. – Hanseh

+1

Heh, tres de las principales respuestas a esta pregunta son "beneficio de rendimiento", "no hay diferencia", "pérdida de rendimiento". –

Respuesta

15

Suponiendo:

  1. Usted ya está usando un motor de almacenamiento que soporta FKs (es decir: InnoDB)
  2. Ya tiene índices en las columnas que participan

Entonces supongo que obtendrás un mejor rendimiento haciendo que MySQL haga cumplir la integridad. La aplicación de la integridad referencial es, después de todo, algo para lo que los motores de base de datos están optimizados. Escribir su propio código para administrar la integridad en Ruby será lento en comparación.

Si necesita pasar de MyISAM a InnoDB para obtener la funcionalidad de FK, debe considerar las compensaciones en el rendimiento entre los dos motores.

Si aún no tiene indicios, debe decidir si los quiere. En términos generales, si está haciendo más lecturas que escrituras, quiere (necesita, incluso) los indicios.

Apilar un FK encima de las cosas que se indexan actualmente debería causar un impacto de rendimiento general menor que implementar ese tipo de controles en el código de la aplicación.

5

En términos generales, más claves (extranjeras o de otro tipo) reducirán el rendimiento de INSERT/UPDATE y aumentarán el rendimiento de SELECT.

El beneficio adicional de la integridad de los datos, es probable que valga la pena la pequeña disminución en el rendimiento que implica agregar las claves externas. ¿De qué sirve una aplicación rápida si los datos que contiene son basura (piezas faltantes, etc.)?

encontrado una consulta similar aquí: Does Foreign Key improve query performance?

3

Debe definir claves externas. En general (aunque no conozco los detalles sobre mySQL), no hay efecto en las consultas (y cuando hay un optimizador, como el optimizador basado en Costos en Oracle, incluso puede tener efectos positivos, ya que el optimizador puede confiar en el información de clave extranjera para elegir mejores planes de acceso). Según el efecto en la inserción y la actualización, puede haber un impacto, pero los beneficios que obtiene (integridad referencial y coherencia de los datos) superan ampliamente el impacto en el rendimiento. Por supuesto, puede diseñar un sistema que no funcione en absoluto, pero la razón principal no será porque haya agregado las claves externas. Y el impacto en mantener su código cuando decide usar otro idioma, o porque las reglas comerciales han cambiado levemente, o porque un nuevo programador se une a su equipo, etc., es mucho más costoso que el impacto en el rendimiento. Mi recomendación, entonces, es sí, vaya y defina las claves externas. Su producto final será más robusto.

1

Dos puntos:
1. ¿Está seguro de que comprobar la integridad en el nivel de la aplicación sería mejor en términos de rendimiento?
2. ejecuta tu propia prueba: probar si las FK tienen una influencia positiva o negativa en el rendimiento debería ser casi trivial.

3

Es una buena idea usar claves foráneas porque eso le asegura la consistencia de los datos (no quiere filas huérfanas y otros problemas inconsistentes de datos).

Pero al mismo tiempo, agregar una clave foránea introduce algún golpe de rendimiento. Suponiendo que está utilizando INNODB como motor de almacenamiento, utiliza un índice agrupado para PK, donde esencialmente los datos se almacenan junto con el PK. Para acceder a los datos utilizando el índice secundario, se requiere pasar el árbol de índice secundario (donde los nodos contienen el PK) y luego pasar por el índice agrupado para obtener realmente los datos. Por lo tanto, cualquier archivo DML de la tabla principal que involucre al FK en cuestión requerirá dos pasadas sobre el índice en la tabla secundaria. Por supuesto, el impacto del golpe de rendimiento depende de la cantidad de datos, el rendimiento del disco y las limitaciones de memoria (datos/índice en caché). Por lo tanto, es mejor medirlo con su sistema objetivo en mente. Diría que la mejor manera de medirlo es con los datos objetivo de muestra, o al menos algunos datos de destino representativos para su sistema. Luego intente ejecutar algunos puntos de referencia con y sin restricciones FK. Escriba los scripts del lado del cliente que generan la misma carga en ambos casos.

Sin embargo, si está comprobando manualmente las restricciones de FK, le recomendaría dejarlo en mysql y dejar que mysql lo maneje.

Cuestiones relacionadas