clé primaire et index sql
Supposons que j'ai une ligne ID (int) dans une base de données définie comme clé primaire. Si j'interroge souvent l'ID, dois-je également l'indexer? Ou est-ce que c'est une clé primaire qui signifie qu'elle est déjà indexée?
La raison pour laquelle je pose cette question est parce que dans MS SQL Server, je peux créer un index sur cet ID, qui, comme je l’ai indiqué, est ma clé primaire.
Edit: une question supplémentaire - Est-il nuisible d'indexer en outre la clé primaire?
Vous avez raison, il est déroutant de constater que SQL Server vous permet de créer des index en double sur le même champ. Mais le fait que vous puissiez en créer un autre n'indique pas que l'indice PK n'existe pas déjà.
L'index supplémentaire ne sert à rien, mais le seul inconvénient (très petit) est la taille de fichier supplémentaire et la charge de création de lignes.
Comme tout le monde l’a déjà dit, les clés primaires sont automatiquement indexées.
La création d'index supplémentaires sur la colonne de clé primaire n'a de sens que lorsque vous devez optimiser une requête utilisant la clé primaire et d'autres colonnes spécifiques. En créant un autre index sur la colonne de clé primaire et en incluant d'autres colonnes, vous pouvez atteindre l'optimisation souhaitée pour une requête.
Par exemple, vous avez une table avec de nombreuses colonnes mais vous interrogez uniquement les colonnes ID, Nom et Adresse. En prenant ID comme clé primaire, nous pouvons créer l'index suivant qui repose sur ID mais inclut les colonnes Nom et Adresse.
CREATE NONCLUSTERED INDEX MyIndex
ON MyTable(ID)
INCLUDE (Name, Address)
Donc, quand vous utilisez cette requête:
SELECT ID, Name, Address FROM MyTable WHERE ID > 1000
SQL Server vous donnera le résultat uniquement en utilisant l'index que vous avez créé et ne lira rien dans la table réelle.
NOTE: Cette réponse concerne le développement de classe entreprise in-the-large .
Ceci est un problème de SGBDR, pas seulement SQL Server, et le comportement peut être très intéressant. D'une part, s'il est courant que les clés primaires soient automatiquement (uniquement) indexées, elles ne sont PAS absolues. Il est parfois essentiel qu'une clé primaire NE soit PAS indexée de manière unique.
Dans la plupart des SGBDR, un index unique sera automatiquement créé sur une clé primaire s'il n'en existe pas déjà. Par conséquent, vous pouvez créer votre propre index sur la colonne de clé primaire avant de la déclarer en tant que clé primaire. Cet index sera utilisé (si acceptable) par le moteur de base de données lorsque vous appliquez la déclaration de clé primaire. Souvent, vous pouvez créer la clé primaire et autoriser la création de son index unique par défaut, puis créer votre propre index alternatif sur cette colonne, puis supprimer l'index par défaut.
Passons maintenant à la partie amusante: quand ne voulez-vous PAS d’un index de clé primaire unique? Vous n'en voulez pas, et vous ne pouvez pas en tolérer, lorsque votre table acquiert suffisamment de données (lignes) pour rendre la maintenance de l'index trop coûteuse. Cela varie en fonction du matériel, du moteur du SGBDR, des caractéristiques de la table et de la base de données, ainsi que de la charge du système. Cependant, il commence généralement à se manifester dès qu'une table atteint quelques millions de lignes.
Le problème essentiel est que chaque insertion d'une ligne ou mise à jour de la colonne de clé primaire entraîne une analyse d'index pour garantir l'unicité. Ce balayage d'index unique (ou son équivalent dans un SGBDR) devient beaucoup plus coûteux à mesure que la table s'agrandit, jusqu'à ce qu'il domine les performances de la table.
J'ai souvent traité ce problème avec des tables pouvant atteindre deux milliards de lignes, 8 To de stockage et quarante millions d'insertions de lignes par jour. J'ai été chargé de redéfinir le système concerné, ce qui incluait la suppression de l'index de clé primaire unique en tant que première étape. En effet, la suppression de cet indice était nécessaire dans la production simplement pour récupérer d'une panne, avant même que nous n'ayons presque refait une refonte. Cette refonte comprenait la recherche d'autres moyens de garantir l'unicité de la clé primaire et de fournir un accès rapide aux données.
Les clés primaires sont toujours indexées par défaut.
Vous pouvez définir une clé primaire dans SQL Server 2012 à l'aide de SQL Server Management Studio ou de Transact-SQL. La création d'une clé primaire crée automatiquement un index unique, en cluster ou non cluster correspondant.
une PK deviendra un index clusterisé, sauf si vous spécifiez non clusterisé
Voici le passage du MSDN :
Lorsque vous spécifiez une contrainte PRIMARY KEY pour une table, le moteur de base de données applique l'unicité des données en créant un index unique pour les colonnes de clé primaire. Cet index permet également un accès rapide aux données lorsque la clé primaire est utilisée dans les requêtes. Par conséquent, les clés primaires choisies doivent suivre les règles pour créer des index uniques.
En faire une clé primaire devrait également créer automatiquement un index pour elle.
En général, dans SQL Server, la clé primaire est automatiquement indexée ..__ Ceci est vrai, mais la rapidité de la requête n'est pas garantie .. La clé primaire vous donnera d'excellentes performances lorsqu'il n'y a qu'un seul champ comme clé primaire . Mais, quand il y a plusieurs champs comme clé primaire, alors l'index est basé sur ces champs.
Par exemple: Les champs A, B, C sont la clé primaire. Ainsi, lorsque vous effectuez une requête en fonction de ces 3 champs dans votre clause WHERE, les performances sont bonnes, MAIS lorsque vous souhaitez interroger avec le champ Only C dans la clause WHERE, vous n'obtiendrez pas de bonnes performances. Ainsi, pour que vos performances soient opérationnelles, vous devrez indexer le champ C manuellement.
La plupart du temps, vous ne verrez pas le problème avant d'avoir atteint plus d'un million de disques.
les clés primaires sont automatiquement indexées
vous pouvez créer des index supplémentaires à l'aide du pk en fonction de votre utilisation
- index Zip_code, id peut être utile si vous sélectionnez souvent par Zip_code et id
J'ai une base de données énorme sans index (séparé).
Chaque fois que j'interroge la clé primaire, les résultats sont instantanés, à toutes fins utiles.
En déclarant une contrainte PRIMARY KEY ou UNIQUE, SQL Server crée automatiquement un index.
Un index unique peut être créé sans faire correspondre une contrainte, mais une contrainte (clé primaire ou unique) ne peut exister sans un index unique.
A partir de là, la création d'une contrainte va:
- provoquer la création d'un index du même nom
- refuser la suppression de l'index créé en tant que contrainte ne peut exister sans elle
et en même temps, la suppression de la contrainte supprimera l'index associé.
Alors, y a-t-il une différence réelle entre un PRIMARY KEY et un UNIQUE INDEX:
- Les valeurs
NULLne sont pas autorisées dansPRIMARY KEY, mais autorisées dansUNIQUEindex; et comme dans les opérateurs d'ensemble (UNION, EXCEPT, INTERSECT), iciNULL = NULL, ce qui signifie que vous ne pouvez avoir qu'une seule valeur car deuxNULLs sont trouvés en double; - un seul
PRIMARY KEYpeut exister par table pendant que 999 des index uniques peuvent être créés - lorsque la contrainte
PRIMARY KEYest créée, elle est créée en tant que cluster sauf si un index en cluster est déjà présent sur la table ou siNONCLUSTEREDest utilisé dans sa définition. LorsqueUNIQUEindex est créé, il est créé sous la formeNONCLUSTEREDsauf s’il n’est pas spécifique d’êtreCLUSTEREDet que cela n’existe pas déjà;