Digamos que tengo una fila de ID (int) en una base de datos establecida como clave principal. Si consulto el ID a menudo, ¿también necesito indexarlo? ¿O es una clave principal lo que significa que ya está indexado?clave primaria sql e índice
Motivo que pido es porque en MS SQL Server puedo crear un índice en este ID, que como indiqué es mi clave principal.
Editar: una pregunta adicional: ¿le hará daño indexar adicionalmente la clave principal?
Tiene razón, es confuso que SQL Server le permita crear índices duplicados en el mismo campo (s). Pero el hecho de que pueda crear otro no indica que el índice PK aún no exista.
El índice adicional no sirve, pero el único daño (muy pequeño) es el tamaño de archivo adicional y la sobrecarga de creación de filas.
claves primarias son indexados automáticamente
puede crear índices adicionales utilizando el pk dependiendo de su uso
Las claves primarias siempre se indexan de forma predeterminada.
Puede definir una clave principal en SQL Server 2012 mediante SQL Server Management Studio o Transact-SQL. La creación de una clave primaria crea automáticamente un índice único, agrupado o no agrupado correspondiente.
que tienen una enorme base de datos con ningún índice (por separado).
Cada vez que consulto por la clave principal, los resultados son, para todos los propósitos intensivos, instantáneos.
una PK se convertirá en un índice agrupado a menos que especifique no agrupado
Por lo que es una clave principal también debe crear automáticamente un índice para él.
Aquí el pasaje de la MSDN:
Cuando se especifica una restricción PRIMARY KEY para una mesa, el motor de base de datos singularidad hace cumplir mediante la creación de un índice único para las columnas de clave principal. Este índice también permite un acceso rápido a los datos cuando la clave principal se utiliza en las consultas. Por lo tanto, las claves principales que se eligen deben seguir las reglas para crear índices únicos.
Como todos los demás ya han dicho, las claves principales se indexan automáticamente.
Crear más índices en la columna de clave primaria solo tiene sentido cuando necesita optimizar una consulta que usa la clave principal y algunas otras columnas específicas. Al crear otro índice en la columna de clave principal e incluir algunas otras columnas con él, puede alcanzar la optimización deseada para una consulta.
Por ejemplo, tiene una tabla con muchas columnas pero solo está consultando las columnas de ID, Nombre y Dirección. Tomando ID como la clave principal, podemos crear el siguiente índice que está construido en ID, pero incluye las columnas Nombre y Dirección.
CREATE NONCLUSTERED INDEX MyIndex
ON MyTable(ID)
INCLUDE (Name, Address)
Por lo tanto, cuando se utiliza esta consulta:
SELECT ID, Name, Address FROM MyTable WHERE ID > 1000
SQL Server le dará el resultado sólo mediante el índice que ha creado y que no va a leer nada de la mesa real.
NOTA: Esta respuesta aborda el desarrollo de clase empresarial en-el-grande.
Este es un problema RDBMS, no solo SQL Server, y el comportamiento puede ser muy interesante. Por un lado, si bien es común que las claves primarias se indexen automáticamente (de manera única), NO es absoluto. Hay momentos en los que es esencial que una clave principal NO esté indexada de forma exclusiva.
En la mayoría de los RDBMS, un índice único se creará automáticamente en una clave primaria si aún no existe. Por lo tanto, puede crear su propio índice en la columna de la clave principal antes de declararlo como clave principal, luego el motor de la base de datos lo usará (si es aceptable) cuando aplique la declaración de la clave principal. A menudo, puede crear la clave principal y permitir que se cree su índice exclusivo predeterminado, luego crear su propio índice alternativo en esa columna y luego soltar el índice predeterminado.
Ahora, para la parte divertida, ¿cuándo NO quieres un índice de clave principal único? No desea uno, y no puede tolerar uno, cuando su tabla adquiera datos suficientes (filas) para que el mantenimiento del índice sea demasiado caro. Esto varía según el hardware, el motor RDBMS, las características de la tabla y la base de datos, y la carga del sistema. Sin embargo, típicamente comienza a manifestarse una vez que una tabla alcanza algunos millones de filas.
El problema esencial es que cada inserción de una fila o actualización de la columna de clave principal da como resultado una exploración de índice para garantizar la exclusividad. Esa exploración de índice única (o su equivalente en cualquier RDBMS) se vuelve mucho más cara a medida que la tabla crece, hasta que domina el rendimiento de la tabla.
He tratado este problema muchas veces con tablas de hasta dos mil millones de filas, 8 TB de almacenamiento y cuarenta millones de insertos de fila por día. Me encargaron rediseñar el sistema involucrado, que incluía dejar caer el índice de clave primaria único prácticamente como el primer paso. De hecho, la caída de ese índice fue necesaria en la producción simplemente para recuperarse de una interrupción, incluso antes de que nos acercáramos a un rediseño. Ese rediseño incluyó encontrar otras formas de garantizar la singularidad de la clave principal y proporcionar un acceso rápido a los datos.
Wow. Comentario/trabajo interesante. – Ryan
(mind == blown) – quillbreaker
¿Qué pasa si la clave es una clave de autoincrement int o bigint? ¿Es SQL Server lo suficientemente inteligente como para no hacer un escaneo de índice único en este caso? – quillbreaker
Bueno, en SQL Server, en general, la clave principal se indexa automáticamente. Esto es cierto, pero no garantiza una consulta más rápida. La clave principal le proporcionará un excelente rendimiento cuando solo hay 1 campo como clave principal. Pero, cuando hay varios campos como clave principal, el índice se basa en esos campos.
Por ejemplo: campo A, B, C son la clave principal, por lo tanto cuando se hace consulta basada en los 3 campos en la cláusula WHERE, el rendimiento es bueno, pero cuando se quiere consultar con el campo C Sólo en la CLÁUSULA DONDE, no obtendrás un buen rendimiento. Por lo tanto, para que su rendimiento funcione, necesitará indexar el campo C manualmente.
La mayoría de las veces, no verá el problema hasta que llegue a más de 1 millón de registros.
El daño de los índices no utilizados es muy perjudicial. Por un lado, los índices consumen almacenamiento. Por otro lado, ralentiza las escrituras y las actualizaciones. Siempre borre los índices que no van a ser utilizados. – Pacerier