Índice agrupado: índice de varias partes frente a parte única y efectos de inserciones/eliminaciones

Question

Esta pregunta trata de lo que sucede con la reorganización de datos en un índice agrupado cuando se realiza una inserción. Supongo que debería ser más costoso hacer inserciones en una tabla que tiene un índice agrupado que una que no lo hace porque reorganizar los datos en un índice agrupado implica cambiar el diseño físico de los datos en el disco. No estoy seguro de cómo expresar mi pregunta, excepto a través de un ejemplo que encontré en el trabajo.

Supongamos que hay una tabla (basura) y hay dos consultas que se realizan en la tabla, la primera busca por Nombre y la segunda busca por Nombre y Algo. Como estoy trabajando en la base de datos descubrí que la tabla se ha creado con dos índices, uno para apoyar cada consulta, así:

--drop table Junk1 
CREATE TABLE Junk1 
(
    Name char(5), 
    Something char(5), 
    WhoCares int 
) 

CREATE CLUSTERED INDEX IX_Name ON Junk1 
(
    Name 
) 

CREATE NONCLUSTERED INDEX IX_Name_Something ON Junk1 
(
    Name, Something 
) 

Ahora cuando miraba a los dos índices, parece que es IX_Name redundante dado que IX_Name_Something puede ser utilizado por cualquier consulta que desee buscar por Nombre. Así que me gustaría eliminar IX_Name y hacer IX_Name_Something el índice agrupado en su lugar:

--drop table Junk2 
CREATE TABLE Junk2 
(
    Name char(5), 
    Something char(5), 
    WhoCares int 
) 

CREATE CLUSTERED INDEX IX_Name_Something ON Junk2 
(
    Name, Something 
) 

Alguien sugirió que el primer esquema de indexación debe mantenerse ya que resultaría en más eficientes inserciones/eliminaciones (suponiendo que no hay necesidad de preocuparse actualizaciones para Nombre y Algo). ¿Eso tendría sentido? Creo que el segundo método de indexación sería mejor, ya que significa que se necesita mantener un índice menor.

Agradecería cualquier idea sobre este ejemplo específico o me indicará más información sobre el mantenimiento de los índices agrupados.

Answer 1

Sí, insertar en el medio de una tabla existente (o su página) podría ser costoso cuando tiene un índice agrupado menos que óptimo. El peor caso sería una división de página: la mitad de las filas de la página deberían trasladarse a otra parte, y los índices (incluidos los índices no agrupados en esa tabla) deben actualizarse.

Usted puede aliviar ese problema mediante el uso de la derecha índice agrupado - uno que, idealmente, es decir:

• estrecha (sólo un único campo, lo más pequeño posible)
• estática (no cambia)
• único (para que SQL Server no necesita agregar uniqueifiers de 4 bytes a sus filas)
• cada vez mayores (como un INT) IDENTIDAD

Desea una clave estrecha (idealmente, una única INT) ya que todas y cada una de las entradas en todos y cada uno de los índices no agrupados también contendrán las claves de clúster: no desea poner muchas columnas en la clave de clúster, ¡ni quieres poner cosas como VARCHAR (200) allí!

Con un índice agrupado cada vez mayor, nunca verá el caso de una división de página. La única fragmentación que puede encontrar es de eliminaciones (problema de "queso suizo").

Echa un vistazo a los mensajes de Kimberly Tripp excellet de blog en la indexación - más notablemente:

• GUIDs as PRIMARY KEYs and/or the clustering key
• The Clustered Index Debate Continues... - éste realidad muestra que un buen índice agrupado se velocidad todas las operaciones - incluidas las plantillas, eliminar etc., en comparación con un montón sin índice agrupado!
• Ever-increasing clustering key - the Clustered Index Debate..........again!

asumir que hay una mesa (no deseado) y hay dos consultas que se realizan en la tabla, las primeras búsquedas de consulta por Nombre y el segundo búsquedas de consulta por Nombre y Alguna cosa. Como estoy trabajando en la base de datos que descubrió que la mesa ha sido creado con dos índices, uno para apoyar cada consulta, así:

Eso definitivamente no es necesario - si usted tiene un índice de (Name, Something), ese índice también se puede usar si se busca y restringe solo en WHERE Name = abc - tener un índice separado con solo la columna Name es totalmente innecesario y solo desperdicia espacio (y le cuesta tiempo mantenerse actualizado).

Básicamente, solo necesita un único índice en (Name, Something), y estoy de acuerdo con usted: si no tiene otros índices en esta tabla, entonces debería poder hacer que esta sea la clave agrupada. Dado que esa clave no será siempre creciente y posiblemente también pueda cambiar (¿no?), Esta podría no ser una gran idea.

La otra opción sería introducir un sustituto ID INT IDENTITY y clúster en que - con dos ventajas:

• Es todo una buena clave agrupada debe ser, incluyendo cada vez mayor -> usted nunca tendrá ningún problemas con divisiones de página y el rendimiento de las operaciones INSERT
• sigue recibiendo todos los beneficios de tener una clave de agrupación (ver entradas de blog Kim Tripps' - mesas agrupadas son casi siempre preferible a montones)

Answer 2

Alguien sugirió que el primer esquema de indexación debe mantenerse ya que daría lugar a inserciones más eficientes/elimina

Esa es una afirmación falsa. Los datos ordenados son datos ordenados y se realizaría el mismo IO.

SET STATISTICS IO ON 
-- your insert statement here 

Answer 3

Se puede crear un índice agrupado sólo en una columna, no dos o más así que elija la columna que su aplicación será sobre todo en la consulta, como comodines en una consulta sobre fullnames clientes, etc. (ver discussion)