Optimización de las consultas SQL
SQL Report Builder le permite consultar e iterar en esas consultas en un momento dado. Esto resulta útil cuando necesita modificar una consulta sin tener que esperar a que finalice un ciclo de actualización antes de darse cuenta de que una columna o informe que ha creado necesita actualizarse.
Antes de ejecutar una consulta, Commerce Intelligence calcula su costo. El coste tiene en cuenta el tiempo y el número de recursos necesarios para ejecutar una consulta. Si se considera que ese costo es demasiado alto o si el número de filas devueltas supera los límites de Commerce Intelligence, la consulta falla. Para consultar la Data Warehouse, que garantiza que escribirás las consultas más optimizadas posibles, Adobe recomienda lo siguiente.
Uso de SELECT o Selección de todas las columnas
La selección de todas las columnas no constituye una consulta oportuna y fácil de ejecutar. Las consultas que utilizan SELECT *
pueden tardar bastante tiempo en ejecutarse, especialmente si la tabla tiene muchas columnas.
Por este motivo, Adobe recomienda evitar el uso de SELECT *
siempre que sea posible e incluir solo las columnas que necesite:
![](./media_1114624cd2183324f8e73039b1237d15ad6a73aa4.png?width=750&format=png&optimize=medium)
![](./media_1a45e21a22d2877f1ac2588c53f7ecd532bb723a7.png?width=750&format=png&optimize=medium)
Uso de uniones externas completas
Las uniones externas seleccionan la totalidad de ambas tablas que se están uniendo, lo que aumenta el coste de cálculo de la consulta. Esto significa que la consulta tarda más en ejecutarse y es más probable que falle, ya que puede tardar más tiempo que el límite de ejecución en devolver los resultados.
En lugar de utilizar este tipo de combinación, considere la posibilidad de utilizar una combinación interna o izquierda. Las uniones internas devuelven resultados únicamente cuando hay una coincidencia en columnas entre las tablas (por ejemplo, order_id
existe tanto en una tabla típica de customers
como en una tabla de orders
). Las combinaciones de izquierda devuelven todos los resultados de la tabla izquierda (primera) junto con los resultados coincidentes de la tabla derecha (segunda).
Observe cómo puede reescribir una consulta FULL OUTER JOIN:
![](./media_1765590709339b6944c7875ee85a46107e5646c20.png?width=750&format=png&optimize=medium)
![](./media_159c69128943c8c6432eb97adfe9e356866775924.png?width=750&format=png&optimize=medium)
Estas consultas son idénticas en todos los sentidos, excepto en el tipo de JOIN que utilizan.
Uso de varias uniones
Aunque puede incluir varias combinaciones en la consulta, recuerde que puede aumentar el costo de la consulta. Para evitar alcanzar el umbral de coste, Adobe recomienda evitar varias uniones siempre que sea posible.
Uso de filtros
Utilice filtros siempre que sea posible. Las cláusulas WHERE
y HAVING
filtran los resultados y le proporcionan únicamente los datos que realmente desea.
Uso de filtros en cláusulas JOIN
Si utiliza un filtro al realizar una combinación, asegúrese de aplicarlo a ambas tablas de la combinación. Incluso si es redundante, esto reduce el coste de cálculo de la consulta y el tiempo de ejecución.
![](./media_14b880d669b438b8331c7ae10cb1dfe7486a25e34.png?width=750&format=png&optimize=medium)
![](./media_1ef572fe7abdd726342edb8ccb23e6234c4479020.png?width=750&format=png&optimize=medium)
Uso de operadores
Al escribir consultas, considere la posibilidad de utilizar los operadores "menos costosos" posibles. Cada consulta tiene un coste de cálculo, que viene determinado por las funciones, operadores y filtros que conforman la consulta. Algunos operadores requieren menos esfuerzo de cálculo, lo que los hace menos costosos que otros operadores.
Los operadores de comparación (>, <, =, etc.) son los menos costosos, seguidos de LIKE. Operadores SIMILAR A y POSIX, que son los operadores más caros.
Uso de EXISTS frente a IN
El uso de EXISTS
frente a IN
depende del tipo de resultados que esté intentando devolver. Si sólo le interesa un valor único, utilice la cláusula EXISTS
en lugar de IN
. IN
se usa con listas de valores separados por comas, lo que aumenta el costo de cálculo de la consulta.
Cuando se ejecutan IN
consultas, el sistema debe procesar primero la subconsulta (la instrucción IN
) y después toda la consulta basada en la relación especificada en la instrucción IN
. EXISTS
es mucho más eficaz porque la consulta no tiene que ejecutarse varias veces: se devuelve un valor true/false al comprobar la relación especificada en la consulta.
En pocas palabras: el sistema no tiene que procesar tanto al usar EXISTS
.
![](./media_1224068882c5b3d3ac208f2ff5d8d963b89f84fa6.png?width=750&format=png&optimize=medium)
![](./media_1d9cb251fb17aac9d559a707c0a0f9bcffc029f98.png?width=750&format=png&optimize=medium)
Uso de ORDER BY
ORDER BY
es una función costosa en SQL y puede aumentar significativamente el costo de una consulta. Si recibe un mensaje de error que indica que el costo EXPLICAR de la consulta es demasiado alto, intente eliminar ORDER BY
de la consulta a menos que sea necesario.
Esto no quiere decir que ORDER BY
no se pueda usar, simplemente que solo se debe usar cuando sea necesario.
Uso de GROUP BY y ORDER BY
Puede haber algunas situaciones en las que este enfoque no se ajuste a lo que está intentando hacer. La regla general es que si está utilizando GROUP BY
y ORDER BY
, debe colocar las columnas en ambas cláusulas en el mismo orden. Por ejemplo:
![](./media_1a16220eadf0f59ca325283b5414b59a65c3b0f71.png?width=750&format=png&optimize=medium)
![](./media_187e6913b391fb6a42902ef2eb819c3907058aa17.png?width=750&format=png&optimize=medium)
Ajuste
La mejor manera de aprender a escribir SQL -y hacerlo de manera eficiente- es a través de prueba y error. Para encontrar lo que funciona mejor para usted, intente volver a crear algunos informes utilizando solo el editor SQL.