Clúster frente a clave primaria no agrupada

Question

begin transaction; 
create table person_id(person_id integer primary key); 
insert into person_id values(1); 
... snip ... 
insert into person_id values(50000); 
commit; 

Este código tarda unos 0,9 segundos en mi máquina y crea un archivo db ocupando 392K. Estos números se convierten en 1,4 segundos y 864K si cambio la segunda línea a

create table person_id(person_id integer nonclustered primary key); 

¿Por qué es este el caso?

Answer 1

[Solo como una idea]

Tal vez cuando se especifica explícitamente a tomar las columnas enteras como una clave agrupada, que hace precisamente eso. Pero cuando le dices que no use tu columna entera, aún crea un índice detrás de las escenas, pero elige un tipo de datos diferente para hacer eso, supongo, el doble de grande. Entonces, cada una de esas entradas tiene que hacer referencia a los registros en la tabla y aquí va, el tamaño está explotando.

Answer 2

La agrupación de la clave principal la almacena con las filas; esto significa que ocupa menos espacio (ya que no hay bloques de índice separados). Sin embargo, normalmente su principal beneficio es que los escaneos de rango generalmente pueden acceder a las filas que están en el mismo bloque, lo que reduce las operaciones de IO, lo que se vuelve bastante importante cuando tiene un gran conjunto de datos (no 50k de entrada).

Creo que 50k ints es un punto de referencia bastante artificial y no uno que te importe en el mundo real.

Answer 3

Aleatoricé las instrucciones de inserción y realicé la consulta con valores de uno a medio millón. Curiosamente, tanto los archivos db agrupados como los no agrupados ahora ocupan la cantidad exacta de espacio (hasta el byte). Sin embargo, las inserciones en el db agrupado son aún más rápidas.

Para mí esto es contrario a la intuición. Cuando le digo a la base de datos que agrupa estos valores, le digo a la base de datos ... estos valores estarán mejor en este orden cuando regrese para obtenerlos. Cuando no tengo la especificación, básicamente le estoy diciendo a la DB: mire estos valores y organícelos de la manera que quiera, lo que le haga la vida más fácil.

Teóricamente, esta libertad adicional nunca debería ralentizar las consultas. Tal vez no los acelere todo el tiempo, pero nunca los desacelere. ¿Pensamientos?

Answer 4

Una gran respuesta a esta pregunta es disponible sobre el StackExchange DBA: https://dba.stackexchange.com/questions/7741/when-should-a-primary-key-be-declared-non-clustered/7744#7744