Hola a todos. Cuando realizamos trabajos sobre optimización de un entorno de base de datos en general, se suele revisar los parámetros de la base de datos, las esperas, índices, etc. Este tipo de cuestiones es importante, pero cobra más importancia en algunos casos, la revisión de las consultas. Por eso os vamos a enseñar este tipo de consejos para optimizar consultas SQL. Estos consejos son útiles para SQL Server, pero en su mayoría se pueden extrapolar a otras bases de datos relacionales como MySQL. Comencemos.
¿Cómo optimizar consultas SQL Server?
Aunque existen varias factores que pueden influir en el rendimiento de una consulta, como índices, cuellos de botella, bloqueos, recursos del servidor…os vamos a enseñar unos criterios generales para poder optimizar una consulta SQL lo máximo posible, al margen de los recursos del servidor u otro tipo de problemas que afectan indirectamente a la ejecución de la query.
Especificar siempre el schema/owner
Sin entrar en mucho detalle, en SQL Server, todas las tablas tienen un schema / owner para poder facilitarnos la gestión de permisos por ejemplo, o tener una mayor organización de las tablas. En caso de no indicar ninguno (que es lo habitual), se utiliza dbo.
Si nos vamos a SSMS podremos comprobar como las tablas tienen todas ellas delante (salvo que se haya especificado otro schema), el schema dbo.
En una consulta de la aplicación podemos tener:
select id, nombre from alumnos
Si lo ejecutamos, internamente, el motor primero va a buscar el schema al que pertenece entre todos los disponibles y después ejecutará la consulta añadiéndole el schema correspondiente. Por lo que lo más óptimo sería ponerlo directamente en la consulta el schema para evitar esa pérdida de recursos innecesaria. Quedando de la siguiente manera:
select id, nombre from dbo.alumnos
A priori puede no ser tan importante, pero si tenemos una gran aplicación con mil tablas y varios schemas, puede ser una gran pérdida de recursos. También es especial importante en consultas con varios join, ya que si usamos 50 tablas en una select y no especificamos el schema, tiene que localizar esas 50 tablas buscando previamente entre mil tablas, siguiendo el ejemplo.
Utilizar los nombres de columna en vez del operador *
Esto es algo muy común, especialmente cuando se está en desarrollo (aunque se ve también en producción). Siguiendo con la tabla de alumnos del ejemplo anterior, vemos que se ha especificado únicamente id y nombre porque son los campos que necesitamos. Si tuviese 5000 alumnos y 30 campos esta tabla, la información a devolver sería considerable y únicamente necesitaríamos solo 2 campos de los 30 que tiene la tabla. Al usar * recorre todos los registros, de toda la tabla, mostrando todos los campos. Por eso es importante acotar lo máximo posible la información que queremos devolver.
Optimizar consultas SQL Server que usen columnas nullables
Utilizar NOT EXISTS en vez de NOT IN. Al utilizar NOT IN con valores nulos, estos también los compara. Sin embargo, si se NOT EXISTS, solo busca resultado en las filas en la que no tengan valores NULL.
Nombres de los procedimientos almacenados
Evita que los procedimientos almacenados, empiecen por sp_ o SP_, ya que esto provocará que el motor los busque dentro de la base de datos de sistema «master» si no se especifica la base de datos y schema. Para ello debemos llamar su ejecución como:
exec dba_reports.dbo.generateReport
en vez de
exec sp_generateReport
Usar SET NOCOUNT ON en operaciones DML
Cuando utilizamos consultas DML (INSERT, UPDATE, DELETE…), el motor nos devuelve el número de registros afectados. Si son pocos posiblemente no se note la diferencia. Pero si son millones de registros o un número grande, el utilizar este parámetro, evitará que el motor «cuente» todos los registros afectados, ahorrando así un gran esfuerzo al motor.
Evitar usar GROUP BY, ORDER BY, and DISTINCT salvo que sea necesario
Para este tipo de operaciones, el motor crea una tabla temporal, ordena los resultados según los criterios establecidos en ella, y devuelve el resultado de forma ordenada. Esto retrasa la devolución de resultados, por eso, salvo que sea necesario, mejor evitarlos.
Conclusión
Esto es solo una parte de lo que hay que revisar en un entorno para optimizar las consultas de SQL Server, pero si quieres que revisemos tu entorno o unas queries en concreto. Puedes contactar con nosotros sin compromiso en nuestra página de contacto. Somos expertos en bases de datos con una gran experiencia en SQL Server, Oracle, MySQL, PostgreSQL…
¿Aún no conoces Query Performance? Descubre cómo puede ayudarte en tu entorno Oracle. Más información en su página de LinkedIn.
Sígue a GPS en LinkedIn
Fuente: https://dzone.com/articles/7-simple-tips-to-boost-the-performance-of-your-sql
Buen día, tengo una vista en SQL server que para que se genere, necesita invocar a otra vista que a su vez invoca más vistas, me pueden dar un consejo de como optimizar este escenario por favor. Esto genera mucho tiempo cuando intento consultar la vista.
Saludos.
Buenos días,
gracias por contactarnos. Sin conocer el entorno concreto, se podría revisar si existe algún índice en las tablas que se pueda crear para mejorarlo. Por ejemplo si la unión de estas vistas es un campo de fecha y un idPedido por ejemplo, posiblemente se pueda crear un índice por estos campos en las tablas implicadas. O cambiar el orden de los join para asegurarnos que empieza por los más restrictivos. Esperamos haberte ayudado.