Razones para un rendimiento SQL ineficiente
Las sentencias de SQL pueden funcionar mal e ineficiente por una variedad de razones:
- Estadísticas desactualizas haciendo Oracle SQL ineficiente: los planes de ejecución SQL se generan mediante el optimizador basado en costos (CBO). Para que el CBO elija un plan de ejecucion eficiente, necesita mejor informacion para decidir por el mejor plan. entro otra informacion importante estan, el volumen de datos y la distribución de tablas e índices referenciados en las consultas. Sin Estadísticas precisas del optimizador, el CBO puede generar una ejecución subóptima en los planes.
- Falta de estructuras de acceso: ausencia de estructuras de acceso, como índices, vistas materializadas, y particiones es una razón común para el rendimiento de SQL pobre. El conjunto correcto de estructuras de acceso puede mejorar el rendimiento de SQL en varios órdenes de magnitud.
- Selección de plan de ejecución subóptimo: A veces, el CBO puede seleccionar una plano de ejecución subóptimo para una sentencia SQL. Esto ocurre en su mayor parte debido a estimaciones incorrectas de algunos atributos de esa sentencia SQL, como su costo, cardinalidad o predicado selectividad.
- SQL mal construido: Si la instrucción SQL está diseñada mal, no hay mucho que el Optimizador puede hacer para mejorar su rendimiento. Una condición de unión faltante que conduce a un producto cartesiano, o el uso de construcciones SQL más costosas como UNION en lugar de UNION ALL, son sólo un par de ejemplos de diseño ineficiente de SQL.
Ejemplos de SQL ineficiente:
Soluciones:
1. La consulta determina cuántos productos tienen lista precios inferiores al 15% por encima del coste medio del producto. Esta sentencia tiene una subconsulta, lo que significa que la subconsulta se ejecuta para cada fila que se encuentra en la consulta externa. Una mejora es la siguiente:
SELECT COUNT(*) FROM products p,
(SELECT prod_id, AVG(unit_cost) ac FROM costs
GROUP BY prod_id) c
WHERE p.prod_id = c.prod_id AND
p.prod_list_price < 1.15 * c.ac
2. Esta consulta aplica funciones a las columnas de unión, restringiendo las condiciones donde los índices pueden ser usados. Usar una condicion simple seria mejor. De lo contrario, puede ser necesario un índice basado en función.
3. Esta consulta tiene una condición que obliga a una conversión implícita de tipo de datos; la columna ORDER_ID_CHAR es un tipo de carácter y la constante es un tipo numérico. Es mejor convertir la constante o variable a tipo de datos que comparar, entonces quedaria asi:
ORDER_ID_CHAR = ‘1205’
4. La cuarta consulta utiliza una función de conversión de tipo de datos para hacer coincidir los tipos de datos en la comparación. El problema aquí es que la función TO_CHAR se aplica al valor de la columna, más que a la constante. Esto significa que la función se llama para cada fila de la tabla. Eso sería mejor convertir el literal una vez, y no convertir la columna. La mejora es:
SELECT * FROM employees
WHERE salary = TO_NUMBER(:sal)
5. El operador UNION, en contraposición al operador UNION ALL, asegura que no haya filas duplicadas en el conjunto de resultados. Sin embargo, esto requiere un paso extra en el optimizador, para eliminar cualquier duplicado. Si usted sabe que no hay filas en común entre los dos UNION, utilice UNION ALL en lugar de UNION. Esto elimina el un paso adicional innecesario.
Acerca del Autor: Aquí
Contacto: Aquí
Mas información:
https://docs.oracle.com/cd/B19306_01/server.102/b14211/sql_1016.htm#g42927
Artículos recientes: