Tengo una base de datos backend de SQL Server. Tengo entendido que los índices agrupados son más eficientes, pero ordenan físicamente las páginas para que sean eficientes. Entonces, si se trata de un campo ingresado por el usuario, cada vez que se agrega un nuevo registro, es necesario reestructurar toda la tabla.
Esto no puede ser eficiente. Entonces, ¿es eficiente en este caso poner un índice regular en un campo? ¿O simplemente lo dejarías sin indexar?
Respuesta1
Como regla general, solo deberías usar índices agrupados para los campos de Identidad, y los números automáticos son los mejores, ya que están en constante aumento. Actualizar una columna de identidad es algo que debe hacer aproximadamente una vez cada milenio, y ciertamente no durante el tiempo de ejecución de la aplicación, por lo que nunca debería tener que reordenar el contenido de la página mediante una declaración DML estándar.
Dentro de estas restricciones, los índices agrupados son muy, muy eficientes, pero como usted señala, si se usan incorrectamente pueden ser un obstáculo importante para el rendimiento de las declaraciones DML en el campo indexado.
Respuesta breve: no utilice índices agrupados para los campos ingresados por el usuario.
En cuanto a los índices no agrupados, pueden ser una gran ayuda o una advertencia, dependiendo de su uso. Los NCI son muy buenos al recuperar una o una pequeña cantidad de filas, pero el tamaño del índice crece con cada campo que se le agrega, por lo que los índices complicados de muchos campos o índices que solo pueden resolver una consulta en una gran cantidad de filas al mismo tiempo. al menos no proporcionan ganancias y, a menudo, son más un lastre de lo que valen.