Diferencia en el rendimiento del servidor SQL con la clave principal de una o varias columnas?

Question

¿Hay alguna diferencia en el rendimiento (en términos de inserción/actualización & consultas) una tabla si la clave principal es una sola columna (por ejemplo, un GUID generado para cada fila) o varias columnas (por ejemplo, una clave externa GUID + número de desplazamiento)?

Supongo que las velocidades de consulta deberían ser más rápidas si se tiene algo con claves primarias de varias columnas, sin embargo, me imagino que insertarlas sería más lento debido a una verificación única ligeramente más complicada. También me imagino que los tipos de datos de una clave principal de varias columnas también podrían ser importantes (por ejemplo, si una de las columnas fuera de tipo DateTime, agregaría complejidad). Estos son solo mis pensamientos para invocar respuestas & discusión (¡con suerte!) Y no se basan en hechos.

Me doy cuenta de que hay some otros questions que cubren este tema, pero me pregunto acerca de los impactos en el rendimiento en lugar de las preocupaciones de administración/negocios.

Answer 1

Se verá más afectado por (cada componente) de la clave que es (a) longitud variable y (b) el ancho [ancho en lugar de columnas estrechas], que el número de componentes en la clave. A menos que MS lo haya roto nuevamente en la última versión (rompieron Heaps en 2005). El tipo de datos no lo desacelera; el ancho y particularmente la longitud variable (cualquier tipo de datos) sí lo hace. Tenga en cuenta que una columna fija de len se hace variable si está configurada como Nullable. Las columnas de longitud variable en los índices son malas noticias, porque se debe realizar un poco de "desembalaje" en cada acceso para obtener los datos.

Obviamente, mantenga las columnas indexadas lo más angostas posible, utilizando solo columnas fijas y no anulables.

En términos de número de columnas en una clave compuesta, asegúrese de que una columna es más rápida que siete, pero no tanto: tres columnas variables de ancho de grasa son mucho más lentas que siete columnas fijas delgadas.

GUID es, por supuesto, una tecla muy gorda; GUID y todo lo demás es muy, muy gordo; GUID Nullable es material Guiness. Desafortunadamente, es la reacción instintiva a la solución del problema de IDENTIDAD, que a su vez es una consecuencia de no haber elegido buenas claves relacionales naturales. Por lo tanto, es mejor que solucione el problema real en el origen y elija buenas claves naturales; evitar la IDENTIDAD; evitar GUID.

Ajuste de experiencia y rendimiento, no conjeturas.

Answer 2

Depende de sus patrones de acceso, relación de lectura/escritura y si (posiblemente lo más importante) el índice agrupado está definido en la clave principal.

La regla general es hacer que su clave principal sea lo más pequeña posible (32 bit int) y definir el índice agrupado en una clave creciente monótonamente (piense IDENTIDAD) donde sea posible, a menos que tenga búsquedas de rango que forman una gran proporción del consultas contra esa tabla.

Si su aplicación es escribir intensiva, y se define el índice agrupado en la columna de la GUID debe tener en cuenta:

1. Todos los índices no agrupados se contienen la clave del índice agrupado y por lo tanto será más grande. Esto puede tener un efecto negativo de rendimiento si hay muchos índices NC.

2. menos que esté utilizando un 'ordenado' GUID (como un peine o el uso de NEWSEQUENTIALID()), sus inserciones se fragmentarán índice a lo largo del tiempo. Esto significa se necesita un índice normal a reconstruir y posiblemente aumentando la cantidad de espacio libre que queda en las páginas (llene factor de)

Debido a que hay muchos factores en el trabajo (hardware, los patrones de acceso, tamaño de los datos) , Le sugiero que realice algunas pruebas y compare sus circunstancias particulares.

Answer 3

Depende de la indexación y el almacenamiento en cada caso. En igualdad de condiciones, la elección de la clave principal es irrelevante en lo que respecta al rendimiento. La elección de los índices y otras opciones de almacenamiento sería el factor decisivo.

Answer 4

Si su situación va a estar orientada a un mayor número de insertos, entonces la menor huella posible, mejor.

Hay dos cosas que debe separar, el concepto de la clave principal en el nivel de la base de datos y el concepto de la clave que utiliza la aplicación.

¿Por qué necesita un GUID? ¿Va a insertar en el servidor de bases de datos múltiples y luego combinar la información en una base de datos centralizada?

Si ese es el caso, entonces mi recomendación es una identidad seguida de un guid. Índice agrupado en la identidad y Único no agrupado en el GUID. Si usa el GUID como un índice agrupado, sus inserciones de datos estarán por todos lados. Lo que significa que sus datos no se insertarán de forma secuencial, y esto ocasiona problemas de rendimiento ya que su sistema insertará y moverá las páginas aleatoriamente.

Tener sus datos insertados bien en una facción ordenada, gracias a la identidad, es el camino a seguir. Puede dejar la ordenación en la estructura del índice (el único sin clúster que contiene el GUID), que es una estructura mucho más eficiente para ordenar que usar los datos de la tabla.