Currenlty Estoy usando muchas combinaciones internas (alrededor de 7) en mi sp, ¿tiene algún impacto en el rendimiento de SP? La combinación externa izquierda da mejor rendimiento que la unión interna.¿Hay algún problema de rendimiento con Inner Join?
una cosa más si estoy uniendo dos tablas a y b que tiene id columna y id1, ambas r no aceptan nulos. supongo que aquí puedo ir a la unión interna ya que estas columnas están indexadas.
En primer lugar, estos dos están destinados a servir diferentes propósitos. Entonces, la comparación podría no ser válida en todos los casos.
Puede leer más aquí.
combinaciones externas son más caras que las uniones interiores. Lo que voy a decir va a ser controvertido para muchos. Si sintonizas la base de datos correctamente y si no haces nada tonto y si estás utilizando un RDBMS de fuerza profesional, entonces 7 combinaciones internas no deberían ser un problema.
¿Qué quiero decir con ajuste de base de datos? Hay mucho para ajustar la base de datos, pero lo más obvio para verificar es asegurarse de que siempre se une a las columnas que están indexadas.
¿Qué quiero decir con goofy? No use el operador O en su condición de unión. Intente mantener sus uniones en una sola comparación, como una clave externa en una tabla que iguale la clave principal en la otra tabla. Intenta mantener todos los campos clave escritos como enteros.
Si se encuentra con problemas de rendimiento, entonces asegúrese de estudiar el plan de ejecución de la consulta ofensiva. Por ejemplo, puede tener problemas al unirse a tablas realmente grandes, tan grandes que incluso un escaneo de índice es demasiado lento. Es posible que tenga que desnormalizar y proporcionar un filtrado adicional para reducir los tiempos de escaneo. No trates de anticipar esto. La desnormalización se realiza mejor apenas y solo después de que te encuentres con situaciones reales de rendimiento.
¿Dónde estuvo la parte controvertida, una vez más? ¿El número de uniones? Creo que solo depende de qué tablas se unan. Además, buenos consejos sobre las cláusulas 'OR'. Son engañosamente caros, especialmente en SQL Server. – Eric
He trabajado con desarrolladores en el pasado que creían que no deberías ir más allá de tres uniones por motivos de rendimiento. Hubiera estado de acuerdo con eso en la década de 1980, pero hoy no. – Glenn
JOIN se utiliza para un propósito específico & no para el rendimiento.
LEFT OUTER JOIN se utiliza para incluir registros, para los cuales no hay registros coincidentes en la tabla de la derecha. INNER JOIN selecciona registros coincidentes según algunos criterios, en ambas tablas.
Este pequeño tidbit sobre LEFT OUTER JOIN fue súper útil para mí. El cambio a una OUTER JOIN desde un INNER JOIN corta mi consulta de 16 segundos a 50 ms. No estaba buscando en ninguna de las columnas de la mesa unida para que pudiera unirse después de los hechos. –
Para seguir con lo que Glenn said, si se está uniendo a las "cosas tontas", extraerlas en las tablas temporales también puede ser útil.
En una base de datos que trabajé en el pasado la unión estaba en una clave parcial (las tablas tenían claves compuestas, es decir, una clave principal con muchas columnas) y había filtrado adicional en la cláusula where. El filtrado en la cláusula where tomó el conjunto de filas para ser vistas desde varios miles de millones hasta varios miles en un lado de la unión. Unirse a una mesa de varios miles de filas era mucho más fácil que en varios miles de millones. El tiempo de consulta pasó de 20 minutos a 7 segundos, según recuerdo.
También tenga en cuenta que también teníamos subconsultas y UDF (funciones definidas por el usuario), lo que posiblemente se sumó a la necedad.
Las uniones a la izquierda dan diferentes resultados que las juntas internas, por lo que no deben utilizarse como sustitutos. Lo más probable es que indexe lo que necesita. Mientras que los índices se crean automáticamente cuando define una clave principal, no se crean cuando define una clave externa. Por lo tanto, necesitará indexar todas las claves foregin en sus uniones si aún no lo ha hecho.
También verifique su plan de ejecución para ver dónde está el problema.
Para obtener más consejos específicos sobre las formas de mejorar el rendimiento de su consulta, debe mostrarnosla.
La razón por la cual las uniones suelen ser costosas es que la unión puede dar lugar a un número de tuplas más grandes que el tamaño de cualquiera de las tablas.
Sin embargo, a veces los atributos de unión en una tabla determinan funcionalmente una tupla única en otra tabla. en este caso, join puede ser muy barato (pero necesitaría indexar esos atributos).
Esta sería una operación económica independientemente de la cantidad de combinaciones que haya realizado, es más un problema de las dependencias de datos y datos.
Dado que se une a 2 teclas, donde parece que se utiliza la misma clave para ambas tablas, esta debería ser una operación económica, independientemente del tipo de combinación que utilice.
¿tiene índices en las columnas utilizadas para la condición de unión (así como en cualquier columna utilizada para otra condición, como en la cláusula where)? puede * realmente * ayudar. En general, he escuchado que inner es mejor para el rendimiento que el izquierdo, pero lo que debe usarse depende de lo que quiera obtener ^^ –