Agrupe el índice en una columna de fecha y hora siempre en aumento en la tabla de registro?

Question

No soy un DBA ("! Bueno", se le pensando en un momento.)

Tengo una tabla de datos de registro con estas características y patrones de uso:

• Una columna datetime para almacenar marcas de tiempo de registro cuyo valor es cada vez mayor y en su mayoría (pero solo en su mayoría) único
• Inserciones frecuentes (digamos, una docena por minuto), solo al final del rango de marca de tiempo (se registran datos nuevos))
• Eliminaciones infrecuentes, a granel, fr om la comenzando de la gama de marca de tiempo (datos antiguos se borran)
• No hay actualizaciones en todos los
• selecciona frecuentes-ish utilizando la columna de la marca de tiempo como el criterio principal, junto con criterios secundarios en otras columnas
• Selecciona poco frecuentes utilizando otras columnas como los criterios (y no incluida la columna de marca de tiempo)
• Una buena cantidad de datos, pero ni de lejos suficiente como para que me preocupa mucho acerca de espacio de almacenamiento

Además, actualmente hay una ventana de mantenimiento diario durante la cual podría hacer la optimización de la tabla.

Francamente, no espero que esta tabla desafíe al servidor en el que va a estar, incluso si lo indexé un poco, pero me pareció una buena oportunidad para solicitar información sobre los índices en clúster de SQL Server.

Sé que los índices agrupados determinan el almacenamiento de los datos reales de la tabla (los datos se almacenan en los nodos hoja del índice) y que los índices no agrupados son punteros separados en los datos. Entonces, en términos de consulta, un índice agrupado va a ser más rápido que un índice no agrupado: una vez que encontramos el valor del índice, los datos están ahí. Hay costos de inserción y eliminación (y, por supuesto, una actualización que cambia el valor de la columna del índice agrupado sería particularmente costoso).

Pero leo in this answer que elimina huecos que no se limpian hasta/a menos que se reconstruya el índice.

Todo esto sugiere a mí que yo debería:

• Poner un índice agrupado en la columna de la marca de tiempo con un factor de relleno 100%
• índices no agrupados poner en cualquier otra columna que puede ser utilizado como criterio en una consulta que tampoco implica la columna agrupada (que puede ser cualquiera de ellos en mi caso)
• Horario elimina el grueso que se produzca durante el intervalo de mantenimiento diario
• Planificar una reconstrucción del clúster índice que se produce inmediatamente después del volumen de lete
• relajarse y salir más

Am I de base muy alejada de allí? ¿Necesito reconstruir el índice con frecuencia de esa manera para evitar mucho espacio desperdiciado? ¿Hay otras cosas obvias (para un DBA) que debería estar haciendo?

Gracias de antemano.

Answer 1

Estoy de acuerdo con poner el índice agrupado en la columna de marca de tiempo. Mi consulta estaría en el factor de relleno: el 100% proporciona el mejor rendimiento de lectura a expensas del rendimiento de escritura. puede verse perjudicado por divisiones de página. Elegir un factor de relleno inferior retrasará la división de la página a expensas del rendimiento de lectura, por lo que es un buen acto de equilibrio para obtener lo mejor para su situación.

Después de que la mayoría borre, vale la pena reconstruir los índices y actualizar las estadísticas. Esto no solo mantiene el rendimiento sino que también restablece los índices al factor de relleno especificado.

Finalmente, sí, coloque índices no agrupados en otras columnas apropiadas, pero solo las que son muy selectas, por ejemplo, no campos de bits. Pero recuerde que cuantos más índices, más esto afecta el rendimiento de escritura

Answer 2

Hay dos maneras de "mejores prácticas" para indexar una tabla de registro de alto tráfico:

1. una columna de identidad número entero como una clave Colum
2. un uniqueidentifier agrupado primaria como clave primaria, con DEFAULT NEWSEQUENTIALID()

Ambos métodos permiten que SQL Server haga crecer la tabla de manera eficiente, porque sabe que el árbol de índice crecerá en una dirección particular.

No pondré ningún otro índice en la tabla ni programaré reconstrucciones del índice, a menos que haya un problema de rendimiento específico.

Answer 3

La respuesta obvia es que depende de cómo lo consulte. El objetivo del índice es disminuir la cantidad de comparaciones cuando se seleccionan los datos. El índice agrupado ayuda cuando considera qué datos va a cargar juntos y el factor de bloqueo del almacenamiento (puede cargar un montón de datos en un bloque de 64k con una lectura). Si incluye una ID y una fecha y hora como la clave principal, pero no las usa en sus criterios de selección, no harán más que obstaculizar su rendimiento. Esta es la razón por la que, por lo general, las personas colocan índices en inserciones en bloque antes de cargar datos.

Answer 4

Al contrario de lo que mucha gente cree, tener un buen índice agrupado en una tabla realmente puede hacer que las operaciones como INSERT sean más rápidas, ¡sí, más rápido!

Echa un vistazo a la publicación seminal del blog The Clustered Index Debate Continues.... por Kimberly Tripp, la reina de la indexación definitiva.

Ella menciona (aproximadamente en el centro del artículo):

inserciones son más rápidos en un tabla agrupada (pero sólo en el "derecho" tabla agrupada) que en comparación con un montón . El problema principal aquí es que las búsquedas en IAM/PFS para determinar la ubicación de inserción en un montón son más lentas que en una tabla agrupada (donde se conoce la ubicación de inserción, definida por la clave agrupada). Las inserciones son más rápidas cuando se insertan en una tabla donde se define el orden (CL) y donde esa orden es cada vez mayor.

El punto crucial es: Sólo con la derecha índice agrupado va a ser capaz de aprovechar los beneficios - cuando un índice agrupado es única, estrecha, estable y de manera óptima cada vez mayor. Esto se sirve mejor con una columna INT IDENTITY.

Kimberly Tripp también tiene un gran artículo sobre cómo elegir la mejor clave de agrupación posible para sus mesas, y qué criterios debe cumplir - ver a su post titulado Ever-increasing clustering key - the Clustered Index Debate..........again!

Si tiene una columna de este tipo - por ejemplo, una clave primaria sustituta: utilícela para su clave de agrupación y debería ver un rendimiento muy bueno en su mesa, incluso en muchos INSERT.