Está en la página 1de 2

¿Qué áreas deben considerar los DBA para el ajuste del rendimiento de las

bases de datos?

El ajuste del rendimiento comienza desde la etapa de diseño de la base de datos y


la aplicación. Las bases de datos y las aplicaciones que están diseñadas teniendo
en cuenta la perspectiva del ajuste del rendimiento son mucho más escalables que
las aplicaciones diseñadas sin esta. Entre algunas áreas podemos mencionar:

 Mala gestión de la conexión: los desarrolladores escriben el código para


conectarse a la base de datos en la aplicación o ejecutan consultas para
obtener los datos de la base de datos, una vez que se han obtenido los
datos y no se requiere nada más, el código debe cerrar la conexión a la
base de datos. Sin embargo, esto a menudo no sucede.

 SQL incorrecto: la forma en que se escribe una consulta SQL afecta


significativamente el rendimiento de ese SQL. Mediante el uso de cursores,
variables de enlace e índices, puede aumentar la eficiencia.

 Obtención incorrecta de entrada y salida de la base de datos: un DBA que


elige el hardware de la base de datos debe intentar distribuir la base de
datos en varios discos e involucrar al equipo de la red en una discusión
sobre la velocidad con la que los datos viajarán a los usuarios finales desde
el servidor de la base de datos y viceversa.

¿Cómo se puede ajustar el rendimiento de SQL mediante la indexación?

La indexación es una forma efectiva de ajustar la base de datos que a menudo se


descuida durante el desarrollo. En términos básicos, un índice es una estructura de
datos que mejora la velocidad de las operaciones de recuperación de datos en una
tabla de base de datos al proporcionar búsquedas aleatorias rápidas y un acceso
eficiente a los registros ordenados. Esto significa que una vez que haya creado un
índice, puede seleccionar u ordenar sus filas más rápido que antes.
Los índices también se utilizan para definir una clave primaria o un índice único
que garantizará que ninguna otra columna tenga los mismos valores.

¿Por qué se debe evitar el “SELECT *”?

Si nuestra aplicación solo necesita unas pocas columnas, no tiene sentido


consultar todos los datos, es un desperdicio masivo de recursos. Esto no es tanto
una regla, sino más bien un medio para prevenir futuros errores del sistema y
ajustes adicionales de rendimiento de SQL.
Sin embargo, tenga en cuenta que hay algunas situaciones en las que el uso de
SELECT * podría ser apropiado. Por ejemplo, con tablas temporales, lo que nos
lleva a nuestro próximo tema.
¿Se recomienda el uso de tablas temporales en la optimización de base de
datos?

Las tablas temporales generalmente aumentan la complejidad de una consulta. Si


nuestro código se puede escribir de una manera simple y directa, se sugiere evitar
las tablas temporales. Si se tiene un procedimiento almacenado con alguna
manipulación de datos que no se puede manejar con una sola consulta, se pueden
usar tablas temporales como intermediarios para generar un resultado final.La
decisión no siempre es sencilla.
Finalmente, cuando haya terminado con su tabla temporal, se debe eliminar para
borrar los recursos tempdb, en lugar de simplemente esperar a que se elimine
automáticamente.

Fuentes:
 https://www.toptal.com/sql-server/sql-database-tuning-for-developers