Este articulo esta enfocado explicar técnicas avanzadas consultas DML con el objetivo de corregir consultas erróneas y resolver problemas de rendimiento que pueden implicar horas (o días) de investigación y pruebas, ademas mejorar las tus técnicas de programación de SQL con estos trucos.
Definiremos «óptimo» como el punto en el que una consulta funciona de manera aceptable y continuará haciéndolo durante un período de tiempo razonable en el futuro.
para el desarrollo de estos ejemplos utilizamos SQL Server 2019 pero aplica en cualquier otra version de sql (EXPRESS , Developer, Estandard o enterprise).
Tecnicas para OR en la cláusula Join / WHERE
la cláusula WHERE o cualquier combinación de filtros que estén separados por un operador AND. Al ser exclusivas, estas operaciones toman datos y los dividen en partes pequeñas.
El operador OR es una historia diferente. Debido a que es inclusivo, SQL Server no puede procesarlo en una sola operación. El escenario en el que OR se desempeña peor es cuando hay varias columnas o tablas involucradas. Incluso si solo hay algunas tablas o columnas involucradas, el rendimiento puede volverse increíblemente malo.
Recordamos que estas sentencias estan dentro del estandard de SQL el cual funciona del mismo modo para cualquier motor de base de datos dígase: SQL Server ( versión EXPRESS , Developer, Estandard o enterprise) , oracle , mysql entre otras.
La mejor manera de lidiar con un OR es eliminarlo (si es posible) o dividirlo en consultas más pequeñas. Dividir una consulta corta y simple en una consulta más larga y extensa puede no parecer elegante, pero cuando se trata de problemas de optimización, a menudo es la mejor opción.
Patrones búsquedas cláusula LIKE
La búsqueda de cadenas de manera eficiente puede ser un desafío, y hay muchas más formas de pulir cadenas de manera ineficiente que eficiente. Para las columnas de cadenas que se buscan con frecuencia, debemos asegurarnos de que:
- Los índices están presentes en las columnas buscadas.
- Los índices están presentes en las columnas buscadas. Se pueden utilizar esos índices.
Sin el uso de características adicionales o consideraciones de diseño, SQL Server no es bueno para la búsqueda de cadenas con la clausula LIKE. Es decir, si quiero detectar la presencia de una cadena en cualquier posición dentro de una columna, obtener esos datos será ineficiente.
Aquí hay una variedad de formas de atacar esta situación, que incluyen:
- Reevalúe la aplicación. ¿Realmente necesitamos hacer una búsqueda con comodines de esta manera? ¿Los usuarios realmente quieren buscar en todas las partes de esta columna una cadena determinada? Si no es así, elimine esta capacidad y el problema desaparecerá.
- ¿Podemos aplicar otros filtros a la consulta para reducir el tamaño de los datos antes de procesar la comparación de cadenas? Si podemos filtrar por fecha, hora, estado o algún otro tipo de criterio de uso común, quizás podamos reducir los datos que necesitamos escanear a una cantidad lo suficientemente pequeña para que nuestra consulta funcione de manera aceptable.
- ¿Podemos hacer una búsqueda de cadenas iniciales, en lugar de una búsqueda con comodines? ¿Se puede cambiar «% para%» por «% para%»?
La búsqueda de cadenas usando clausula LIKE es cara. Nuestras mejores armas en su contra se basan en reglas de diseño y arquitectura que nos permiten eliminar el “%” inicial o limitar la forma en que buscamos de manera que permitan implementar otros filtros o soluciones.
Cuestionario para la Optimización de consultas DML
La pregunta # 1 que siempre debemos responder es: ¿Cuál es el propósito de una consulta?
- ¿Cual es su propósito?
- ¿Cómo debería verse el conjunto de resultados?
- ¿Qué tipo de código, informe o interfaz de usuario genera la consulta?
- ¿Qué tan grande es el conjunto de resultados?
- ¿Hay parámetros que tengan valores limitados?
- ¿Con qué frecuencia se ejecuta la consulta? Algo que ocurre una vez al día se tratará de manera muy diferente a uno que se ejecuta cada segundo.
- ¿Hay valores de entrada no válidos o inusuales que indiquen un problema de aplicación? ¿Se establece una entrada en NULL, pero nunca debería ser NULL?
- ¿Hay algún problema lógico, sintáctico o de optimización obvio que nos esté mirando a la cara?
- ¿Qué tan rápida debe ser la consulta para que sus consumidores estén contentos? Si el rendimiento del servidor es deficiente.
- ¿cuánto debemos reducir el consumo de recursos para que sea aceptable? Por último,
- ¿cuál es el rendimiento actual de la consulta? Esto nos proporcionará una línea de base para que sepamos cuántas mejoras se necesitan.
Lo idoneo es tener todas estas preguntas resultas antes de empezar a escribir la consultas y dar respuesta a las necesidades esto no permitira entregar un resultado mas optimo y nuestros usuarios.
Este articulo a cubierto algunas de técnicas las técnicas avanzadas consultas DML a ser consideradas para los fines de optimizar las consultas SQL generadas estas técnicas son imprescindibles para poder generar consultas y procedimientos con un alto nivel de rendimiento, ademas aprendimos las técnicas de programación de SQL necesarias para mejorar nuestro código
Ver entrada relacionadas
[pt_view id=»a71a788m75″]
