Seis leyes de hierro de la gestión de índices de SQL Server

El índice es un objeto de base de datos basado en columnas de tabla. El índice almacena las columnas de índice ordenadas en la tabla y registra la ubicación de almacenamiento físico de las columnas de índice en la tabla de base de datos. datos en la tabla a través del índice puede acelerar la consulta de datos y reducir el tiempo de respuesta del sistema; puede acelerar la conexión entre tablas.

Sin embargo, este efecto no se puede lograr utilizando índices en ningún momento. se usa en situaciones inapropiadas. El uso de índices será contraproducente, por lo que aún debe seguir ciertas reglas al usar índices en una base de datos de SQL Server. Creo que es principalmente necesario cumplir con seis leyes de hierro.

Allí. No hay almuerzos gratis en el mundo. El uso de índices es necesario. Pagar el precio

Las ventajas de la indexación son obvias, pero pocas personas se preocupan por el costo de usar índices si los administradores de bases de datos pueden tener un conocimiento completo de ello. los costos de indexación, no será tan casual al crear índices en todas partes

Si cuenta con cuidado, el costo de crear un índice sigue siendo bastante alto. Por ejemplo, crear y mantener índices requiere tiempo y energía. Especialmente la gestión de la base de datos durante el diseño de la base de datos. Es necesario investigar y coordinar qué campos de la tabla deben indexarse. Por ejemplo, cuando los registros de la tabla indexada se eliminan y modifican, la base de datos debe reajustar el índice. La base de datos lo completará automáticamente y consumirá recursos del servidor. Cuando hay más datos en la tabla, se consumen más recursos. Por ejemplo, los índices son objetos que realmente existen en la base de datos, por lo que cada índice ocupará una cierta cantidad de. espacio físico Si hay demasiados índices, no solo ocupará mucho espacio físico sino que también afectará el rendimiento de ejecución de toda la base de datos

Se puede ver que si. El administrador de la base de datos usa índices para mejorar el rendimiento del sistema, pero todavía necesita pagar mucho dinero. Lo que el administrador de la base de datos ahora debe considerar es cómo mejorar el rendimiento del sistema. punto crítico entre retorno e inversión

Regla de hierro 2: no crear índices para columnas que rara vez participan en consultas o columnas con muchos valores duplicados

Al realizar consultas, si no consultamos por un determinado campo, es un desperdicio crear un índice en este campo. Por ejemplo, si hay una tabla de información de empleados, podemos consultar la información de los empleados por número de empleado, nombre de empleado o lugar de origen, pero a menudo no lo hacemos. La consulta se basará en el número de identificación. Aunque este número de identificación es único, incluso si crea un índice en este campo, no mejorará la velocidad de la consulta. Por el contrario, aumentará el tiempo de mantenimiento del sistema y ocupará el espacio del sistema. Esto es simplemente dispararse a sí mismo.

Además, en la tabla de información del empleado anterior, algunos campos tienen valores más repetidos. Por ejemplo, el campo de género es principalmente "masculino" y "femenino"; también tiene una cantidad limitada de contenidos. En este momento, agregar un índice a estos campos no aumentará significativamente la velocidad de consulta ni reducirá el tiempo de respuesta del usuario. Por el contrario, reducirá el rendimiento general de la base de datos porque requiere espacio.

La segunda regla de hierro en la gestión de índices de bases de datos es que rara vez se involucra en consultas. No cree índices para columnas o columnas con muchos valores repetidos

Regla de hierro 3: es mejor crear índices. para columnas que se consultan por rango

En los sistemas de gestión de información, a menudo es necesario crear índices por rango para consultar ciertos registros de transacciones. Por ejemplo, en el sistema ERP, a menudo es necesario consultar las ventas. pedidos y envíos de ventas del mes actual. Esto requiere consultar los registros de transacciones por rango de fechas. Por ejemplo, a veces, cuando se descubre que el inventario es incorrecto, también es necesario consultar el inventario dentro y fuera de un determinado período de tiempo, como por ejemplo. como el mes, las transacciones de inventario de un día a otro, etc., también se consultan según la fecha.

Para estas columnas de datos que deben consultarse rápidamente o con frecuencia dentro de un rango específico, es necesario crear índices porque el los índices se han ordenado y guardado Cuando el rango especificado es continuo, la consulta puede utilizar la clasificación de índices para acelerar el tiempo de consulta y reducir el tiempo de espera del usuario.

Sin embargo, aunque puede ser necesario realizar la consulta por rango, si. las condiciones de consulta en este rango no se usan mucho. Es mejor no usar un índice. Por ejemplo, en la tabla de información de empleados, es posible que deba consultar los detalles de los empleados que se unieron antes del año y mes.

Es necesario aumentar los beneficios para ellos, pero como no hay muchos registros en la tabla y rara vez se realizan consultas similares, es inofensivo indexar este campo, pero es obvio que los beneficios obtenidos del índice son menores que su costo. , lo cual no vale la pena para el administrador de la base de datos.

Además, si usa una consulta de rango, es mejor usar la palabra clave TOP para limitar los resultados de una consulta, como mostrar solo la anterior. registros en orden por primera vez, etc. Utilice la palabra clave TOP con el rango. Puede mejorar en gran medida la eficiencia de la consulta.

Regla de hierro 4: si hay una clave primaria o una clave externa en la tabla, debe estar indexada

Si la columna de índice que define la clave principal debe estar indexada Debido a que la clave principal puede acelerar la ubicación en una determinada fila de la tabla, combinada con el índice, puede duplicar la velocidad de Por ejemplo, en la tabla de información del empleado, a menudo establecemos el número del empleado como clave principal porque esto no solo mejora la velocidad de la consulta, sino que también requiere la unicidad del registro. número de empleado En este momento, si el campo de número de empleado se establece como índice, la eficiencia de consultar la información del empleado a través del número de empleado será mucho mayor que sin establecer un índice.

Además, si quiero hacer un cierto El valor único de un campo se puede lograr mediante dos métodos de índice, uno es el índice de clave principal mencionado anteriormente y el otro es el índice único que utiliza la palabra clave UNIQUE para especificar la unicidad del contenido del campo. Los métodos se utilizarán automáticamente en las columnas especificadas de la tabla. No existe una diferencia obvia en los resultados de los dos métodos para crear un índice único. El optimizador de consultas no distinguirá qué método se utiliza para crear un índice único y la forma. realizan consultas de datos también es lo mismo

Si una tabla Si la definición de la columna de datos tiene una clave externa, es mejor crear un índice para este campo porque la función principal de la clave externa es conectar los consulta entre las tablas Si crea un índice en la clave externa, puede acelerar la consulta para conectar la tabla. Por ejemplo, hay un campo en la tabla de información básica del empleado para el puesto del empleado. Lo que se almacena aquí es en realidad solo el código de un puesto de empleado. En otra tabla de información de puesto, la información relevante del puesto se registra en detalle. En este momento, el campo de puesto de empleado es si se establece una clave externa en este campo. , la velocidad de conexión de las dos tablas se puede mejorar significativamente y cuantos más registros, más obvio será el efecto

Por lo tanto, cuando hay una clave externa o una clave primaria en la tabla, es mejor Es mejor crear un índice para ello. La indexación puede fortalecer el papel de las claves primarias y externas y mejorar el rendimiento de la base de datos.

Regla de hierro 5: no cree índices para algunos tipos de datos especiales

Hay algunos campos en la tabla especiales, como campos de texto (TXT), campos de tipo imagen (IMAGE), etc. Si los campos de la tabla pertenecen a estos tipos de datos, es mejor no indexarlos porque estos Los campos tienen algunas características diferentes, como longitudes inciertas o muy largas. Unos pocos caracteres o es una cadena vacía, como un tipo de datos de texto que a menudo se usa para hacer notas en tablas de bases de datos de sistemas de aplicaciones. es muy largo pero a veces no hay datos. Si se crea un índice en este tipo de campo, no tiene ningún efecto. Por el contrario, también aumenta la carga sobre el sistema.

Por lo tanto, usted. Se debe tener cuidado al crear índices para algunos tipos de datos especiales. En circunstancias normales, no es necesario crear índices para ellos, pero también hay circunstancias especiales. Por ejemplo, a veces hay una tabla de información del producto en el sistema ERP. es un campo llamado especificaciones del producto. A veces su longitud puede ser de hasta 3 caracteres. En este momento, solo los tipos de datos de texto pueden acomodar una cantidad tan grande de datos y a los usuarios les gusta usar especificaciones al consultar Parámetros para consultar información del producto. Si este campo no está indexado en este momento, la velocidad de consulta será muy lenta. Cuando se encuentre con esta situación, el administrador de la base de datos tendrá que sacrificar algunos recursos del sistema para indexarlo.

Se puede ver desde aquí. aunque las mencionadas anteriormente son leyes de hierro, si es necesario seguirlas aún requiere que el administrador de la base de datos tome decisiones razonables en función de la situación real de la empresa

El índice seis de la ley de hierro se puede integrar con el conjunto de Donde declaraciones integradas

Los usuarios a veces suelen utilizar algunas declaraciones restrictivas cuando consultan información. Por ejemplo, cuando consultan pedidos de ventas, a menudo utilizan un conjunto de condiciones para los clientes y las fechas de los pedidos, por ejemplo, cuando consultan un producto.

Para las transacciones de inventario, se utilizará el conjunto de condiciones de número de producto y fecha de inicio y finalización de la transacción.

Para estas columnas de datos que se utilizan a menudo en la cláusula Where, el índice se establecerá en el proceso de recopilación de la cláusula Where para necesidades Acelerar o recuperar columnas de datos con frecuencia puede permitir que estas columnas de datos que frecuentemente participan en consultas se consulten de acuerdo con el orden del índice para acelerar el tiempo de consulta lishixinzhi/Article/program/SQLServer/201311/22311