¿Cuáles son las mejores formas de escribir una consulta SQL?

Se utiliza una consulta SQL para recuperar los datos necesarios de la base de datos. Sin embargo, puede haber múltiples consultas SQL que arrojen los mismos resultados pero con diferentes niveles de eficiencia. Una consulta ineficiente puede agotar los recursos de la base de datos, reducir la velocidad de la base de datos o provocar una pérdida de servicio para otros usuarios. Por eso es muy importante optimizar la consulta para obtener el mejor rendimiento de la base de datos.

Consideremos algunas tablas de muestra para comprender estos diferentes métodos para optimizar una consulta.

Clientes: la tabla Clientes contiene los detalles de los posibles clientes de una tienda.

Identificación del cliente	Apellido	Primer nombre	Dirección	Años
73001	Herrero	John	45 Calle Salto	21
73002	parker	ana	83 Avenida Salvaje	45
73003	Jaime	Josefina	Avenida Castaño 99	25
73004	Blanco	ana	Calle de papel 55	72
73005	chispas	Harry	Calle de las glicinias, 11	23
73006	parker	jane	Calle Quentin, 12	50

Productos: la tabla Productos contiene los detalles de los productos disponibles en la tienda.

Identificación de producto	Nombre del producto	Precio del producto
1001	Champú	100
1002	Pasta dental	20
1003	Jabón	15
1004	Alcohol en gel	50
1005	Desodorante	100

Pedidos: La tabla Pedidos contiene los detalles de los productos pedidos por los clientes de la tienda.

Identificación del cliente	Identificación de producto	Cantidad de producto
73001	1003	5
73001	1001	1
73003	1002	1
73004	1003	2
73004	1005	1

Ahora que hemos analizado las tablas Clientes , Productos y Pedidos , a continuación se muestran las diferentes formas de optimizar una consulta con ejemplos de consulta de estas tablas:

1. Proporcione el formato correcto para la consulta

Es muy importante proporcionar el formato correcto al escribir una consulta. Esto mejora la legibilidad de la consulta y también facilita su revisión y solución de problemas. Algunas de las reglas para dar formato a una consulta se dan a continuación:

• Coloque cada declaración en la consulta en una nueva línea.
• Ponga las palabras clave de SQL en la consulta en mayúsculas.
• Use mayúsculas y minúsculas CamelCase en la consulta y evite el guión bajo (escriba ProductName y no Product_Name).

Ejemplo: esta es una consulta que muestra el ID de cliente y el apellido de los clientes que han pedido productos actualmente y tienen menos de 50 años.

Select distinct Customers.CustomerID, Customers.LastName from Customers INNER join Orders on Customers.CustomerID = Orders.CustomerID where Customers.Age < 50;

La consulta anterior parece ilegible ya que todas las declaraciones están en una línea y las palabras clave están en minúsculas. Por lo tanto, a continuación se proporciona una versión optimizada utilizando las reglas de formato especificadas anteriormente.

SELECT DISTINCT Customers.CustomerID, Customers.LastName
FROM Customers INNER JOIN Orders
ON Customers.CustomerID = Orders.CustomerID
WHERE Customers.Age < 50;

2. Especifique los campos SELECT en lugar de usar SELECT *

SELECT * se utiliza para obtener todos los datos de una tabla. Por lo tanto, no debe usarse a menos que todos los datos sean realmente necesarios para una condición determinada, ya que es muy ineficiente y ralentiza el tiempo de ejecución de la consulta. Es mucho mejor usar SELECT junto con los campos específicos requeridos para optimizar la consulta.

Ejemplo: Esta es una consulta que muestra todos los datos en la tabla Clientes cuando solo se requería el CustomerID y el Apellido .

SELECT * 
FROM Customers;

Es mejor usar la instrucción select con los campos CustomerID y LastName para obtener el resultado deseado.

SELECT CustomerID, LastName 
FROM Customers;

3. Elimine las subconsultas correlacionadas si no es necesario

Una subconsulta correlacionada es una consulta anidada que depende de la consulta externa para sus valores. Si hay millones de usuarios en la base de datos, la subconsulta correlacionada es ineficiente y requiere mucho tiempo, ya que deberá ejecutarse millones de veces. En ese caso, una unión interna es más eficiente.

Ejemplo: esta es una consulta que muestra el CustomerID de los clientes que actualmente ordenaron productos utilizando una subconsulta correlacionada.

SELECT CustomerID
FROM Customers
WHERE EXISTS (SELECT * FROM Orders
              WHERE Customers.CustomerID = Orders.CustomerID);

Es mejor usar la combinación interna en este caso para obtener el mismo resultado.

SELECT DISTINCT Customers.CustomerID
FROM Customers INNER JOIN Orders
ON Customers.CustomerID = Orders.CustomerID;

Nota: es mejor evitar una subconsulta correlacionada si se necesitan casi todas las filas de la base de datos. Sin embargo, en algunos casos, son inevitables y deben usarse.

4. Limitar los resultados obtenidos por la consulta

En caso de que solo se requieran resultados limitados, es mejor usar la instrucción LIMIT. Esta declaración limita los registros y solo muestra la cantidad de registros especificados. Por ejemplo: si hay una gran base de datos de un millón de registros y solo se requieren los primeros diez, es mejor usar la declaración LIMIT ya que esto garantizará que solo se obtengan los registros relevantes sin sobrecargar el sistema.

Ejemplo: esta es una consulta que muestra los detalles del cliente con un límite de 3:

SELECT *
FROM Customers 
LIMIT 3;

5. Eliminar la cláusula DISTINCT si no es necesaria

La cláusula DISTINCT se utiliza para obtener resultados distintos de una consulta eliminando los duplicados. Sin embargo, esto aumenta el tiempo de ejecución de la consulta ya que todos los campos duplicados se agrupan. Por lo tanto, es mejor evitar la cláusula DISTINCT tanto como sea posible. Como alternativa, se puede utilizar la cláusula GROUP BY para obtener resultados distintos.

Ejemplo: Esta es una consulta que muestra el Apellido distinto de todos los clientes que usan la cláusula DISTINCT.

select distinct LastName
from Customers;

El apellido distinto de los clientes también se puede obtener utilizando la cláusula GROUP BY, que se demuestra en el siguiente ejemplo:

SELECT LastName
FROM  CUSTOMERS
GROUP BY LastName;

6. Evita funciones en predicados

Las funciones en SQL se utilizan para realizar acciones específicas. Sin embargo, son bastante ineficientes ya que no permiten el uso de índices, lo que a su vez ralentiza el tiempo de ejecución de la consulta. Por lo tanto, es mejor evitar funciones en una consulta tanto como sea posible para garantizar su optimización.

Ejemplo: Esta es una consulta que muestra los detalles de los productos cuyo nombre comienza con ‘ Sha ‘.

SELECT *
FROM Products
WHERE SUBSTR(ProductName, 1, 3) = 'Sha';

Es mejor evitar la función y usar la cláusula LIKE en su lugar para obtener el mismo resultado.

SELECT *
FROM Products
WHERE ProductName LIKE 'Sha%';

7. Evite los operadores OR, AND, NOT si es posible

Es muy probable que los índices no estén en uso cuando se usan los operadores OR, AND, NOT. En el caso de bases de datos grandes, es mejor encontrar reemplazos para estas para acelerar el tiempo de ejecución de la consulta.

A continuación se dan ejemplos de esto para los operadores OR y AND:

Ejemplo 1: esta es una consulta que muestra los detalles de los clientes con CustomerID 73001, 73004 y 73005 utilizando el operador OR.

SELECT * 
FROM Customers
WHERE CustomerID = 73001
OR CustomerID = 73004
OR CustomerID = 73005;

Es mejor usar el operador IN en este caso para obtener el mismo resultado.

SELECT * 
FROM Customers
WHERE CustomerID IN (73001, 73004, 73005);

Ejemplo 2: Esta es una consulta que muestra los detalles de los clientes con edades entre 25 y 50 años utilizando el operador AND.

SELECT * 
FROM Customers
WHERE age >= 25 AND age <= 50;

Es mejor usar el operador BETWEEN en este caso para obtener el mismo resultado.

SELECT * 
FROM Customers
WHERE age BETWEEN 25 AND 50;

8. Utilice la cláusula WHERE en lugar de la cláusula HAVING siempre que sea posible

La cláusula HAVING se usa con la cláusula GROUP BY para hacer cumplir las condiciones, ya que la cláusula WHERE no se puede usar con funciones agregadas. Sin embargo, la cláusula HAVING no permite el uso de índices, lo que ralentiza el tiempo de ejecución de la consulta. Por lo tanto, es mejor usar la cláusula WHERE en lugar de la cláusula HAVING siempre que sea posible.

Ejemplo: esta es una consulta que muestra los Nombres de los clientes con el recuento de clientes que los tienen para los clientes mayores de 25 años. Esto se hace usando la cláusula HAVING.

SELECT FirstName, COUNT(*)
FROM Customers
GROUP BY FirstName
HAVING Age > 25;

Es mejor usar la cláusula WHERE en este caso, ya que aplica la condición a filas individuales en lugar de la cláusula HAVING que aplica la condición al resultado de la cláusula GROUP BY.

SELECT FirstName, COUNT(*)
FROM Customers
where Age > 25
GROUP BY FirstName;

9. Use la cláusula INNER JOIN en lugar de WHERE para crear uniones

El uso de la cláusula WHERE para crear uniones da como resultado un producto cartesiano donde el número de filas es el producto del número de filas de las dos tablas. Obviamente, esto es problemático para bases de datos grandes, ya que se requieren más recursos de base de datos. Por lo tanto, es mucho mejor usar INNER JOIN ya que solo combina las filas de ambas tablas que cumplen la condición requerida.

Ejemplo: esta es una consulta que muestra el CustomerID de los clientes que actualmente ordenaron productos utilizando la cláusula WHERE.

SELECT DISTINCT Customers.CustomerID
FROM Customers, Orders
WHERE Customers.CustomerID = Orders.CustomerID;

Es mejor usar el Inner join en este caso para obtener el mismo resultado.

SELECT DISTINCT Customers.CustomerID
FROM Customers INNER JOIN Orders
ON Customers.CustomerID = Orders.CustomerID;

10. Evite los caracteres comodín al comienzo de un patrón de cláusula LIKE

Los caracteres comodín como % y _ se utilizan para filtrar los resultados de una cláusula LIKE. Sin embargo, no deben usarse al comienzo del patrón, ya que esto impide que la base de datos use el índice. En ese caso, se requiere una exploración completa de la tabla para que coincida con el patrón que consume más recursos de la base de datos. Por lo tanto, es mejor evitar los caracteres comodín al comienzo del patrón y solo usarlos al final si es posible.

Ejemplo:

SELECT * FROM Customers
WHERE FirstName LIKE '%A%'

La consulta anterior es ineficaz ya que utiliza el carácter comodín % al principio del patrón. A continuación se proporciona una versión mucho más eficiente de la consulta que evita esto:

SELECT * FROM Customers
WHERE FirstName LIKE 'A%'