SQL: que font exactement les clés primaires et les index?

Question

J'ai récemment commencé à développer ma première application sérieuse qui utilise une base de données SQL, et j'utilise phpMyAdmin pour configurer les tables. Il y a quelques options « caractéristiques » Je peux donner différentes colonnes, et je ne suis pas tout à fait sûr de ce qu'ils font:

• clé primaire
• Index

Je sais ce que PK est pour et comment l'utiliser, mais je suppose que ma question à ce sujet est de savoir pourquoi en a-t-on besoin - en quoi est-ce différent de simplement mettre une colonne à "Unique", autre que le fait que vous ne pouvez avoir qu'un PK? Est-ce juste pour faire savoir au programmeur que cette valeur identifie de façon unique l'enregistrement? Ou a-t-il des propriétés spéciales aussi? Je n'ai aucune idée de ce que fait "Index" - en fait, les seules fois que je l'ai vu en usage sont (1) que mes clés primaires semblent être indexées, et (2) j'ai entendu que l'indexation est en quelque sorte lié à la performance; que vous voulez des colonnes indexées, mais pas trop. Comment décide-t-on quelles colonnes indexer et que fait-elle exactement?

éditer: est-ce qu'une colonne d'index devrait vouloir ORDER BY?

Merci beaucoup,

Mala

Answer 1

clé primaire est généralement utilisé pour créer un « id » numérique pour vos dossiers, et cette colonne id est automatiquement incrémentée.

Par exemple, si vous avez une table books avec un champ id, où le id est la clé primaire et est également mis à auto_increment (sous « Extra dans phpmyadmin), puis lorsque vous ajoutez un livre à la table, l'identifiant pour cela deviendra 1 '. L'identifiant du livre suivant serait automatiquement '2', et ainsi de suite. Normalement, chaque table devrait avoir au moins une clé primaire pour faciliter l'identification et la recherche de documents facilement.

Les index sont utilisés lorsque vous devez récupérer régulièrement certaines informations d'une table. Par exemple, si vous avez une table users et que vous devez accéder à la colonne email, vous pouvez ajouter un index sur l'e-mail, ce qui accélèrera l'accès aux requêtes.

Cependant, il existe également des inconvénients pour l'ajout d'index inutiles, donc ajoutez ceci uniquement sur les colonnes qui ont vraiment besoin d'être accédées plus que les autres. Par exemple, les requêtes UPDATE, DELETE et INSERT seront un peu plus lentes plus vous aurez d'index, car MySQL a besoin de stocker des informations supplémentaires pour chaque colonne indexée. Plus d'informations peuvent être trouvées au this page.

Modifier: Oui, les colonnes qui doivent être utilisées dans ORDER BY beaucoup doivent avoir des index, ainsi que ceux utilisés dans WHERE.

Answer 2

La clé primaire est fondamentalement une colonne indexée unique qui agit comme l'ID "officiel" des lignes dans cette table. Plus important encore, il est généralement utilisé pour les relations de clés étrangères, c'est-à-dire si une autre table fait référence à une rangée dans la première, elle contiendra une copie de la clé primaire de cette rangée.

Notez qu'il est possible d'avoir une clé primaire composite, c'est-à-dire composée de plusieurs colonnes.

Les index améliorent les temps de recherche. Ils sont généralement basés sur l'arborescence, de sorte que la recherche d'une certaine ligne via un index prend le temps O (log (n)) plutôt que de parcourir la table complète.

Généralement, toute colonne d'une grande table fréquemment utilisée dans les clauses WHERE, ORDER BY ou (spécialement) JOIN doit avoir un index. Depuis l'index doit être mis à jour pour chaque INSERT, UPDATE ou DELETE, il ralentit ces opérations. Si vous avez peu d'écritures et beaucoup de lectures, indexez le contenu de votre écoute. Si vous avez beaucoup d'écritures et beaucoup de requêtes qui nécessiteraient des index sur plusieurs colonnes, alors vous avez un gros problème.

Answer 3

La différence entre une clé primaire et une clé unique est mieux expliquée par un exemple.

Nous avons une table d'utilisateurs:

USER_ID number 
NAME varchar(30) 
EMAIL varchar(50) 

Dans ce tableau, la USER_ID est la clé primaire. Le NOM n'est pas unique - il y a beaucoup de John Smiths et de Muhammed Khans dans le monde. L'EMAIL est nécessairement unique, sinon le système de courrier électronique mondial ne fonctionnerait pas. Nous avons donc mis une contrainte unique sur EMAIL. Pourquoi alors avons-nous besoin d'une clé primaire distincte?

Trois raisons:

1. la clé numérique est plus efficace lorsqu'il est utilisé dans clés étrangères relations car il faut moins d'espace
2. l'e-mail peut changer (par exemple fournisseur swapping) mais l'utilisateur est toujours le même ; ondulant un changement de une valeur de clé primaire à travers un schéma est toujours un cauchemar
3. il est toujours une mauvaise idée d'utiliser des informations sensibles ou privées comme une clé étrangère

Answer 4

Dans le modèle relationnel, tout colonne ou ensemble de colonnes qui est garanti à la fois présent et unique dans la table peut être appelé une clé candidate à la table. "Présent" signifie "NOT NULL". Dans la conception de base de données, il est courant de désigner l'une des clés candidates en tant que clé primaire et d'utiliser des références à la clé primaire pour désigner la ligne entière ou l'élément concerné décrit par la ligne.

En SQL, une contrainte PRIMARY KEY correspond à une contrainte NOT NULL pour chaque colonne de clé primaire et à une contrainte UNIQUE pour toutes les colonnes de clé primaire prises ensemble. En pratique, de nombreuses clés primaires s'avèrent être des colonnes simples.

Pour la plupart des produits SGBD, une contrainte PRIMARY KEY entraîne également la création automatique d'un index sur les colonnes de clé primaire. Cela accélère l'activité de vérification des systèmes lorsque de nouvelles entrées sont effectuées pour la clé primaire, afin de s'assurer que la nouvelle valeur ne duplique pas une valeur existante. Il accélère également les recherches en fonction de la valeur de la clé primaire et des jointures entre la clé primaire et une clé étrangère qui la référence. La vitesse d'exécution dépend du fonctionnement de l'optimiseur de requête. À l'origine, les concepteurs de bases de données relationnelles recherchaient les clés naturelles dans les données telles qu'elles sont données. Ces dernières années, la tendance a toujours été de créer une colonne appelée ID, un entier comme première colonne et la clé primaire de chaque table. La fonctionnalité autogénération du SGBD est utilisée pour s'assurer que cette clé sera unique. Cette tendance est documentée dans les "Normes de conception d'Oslo".Ce n'est pas nécessairement un design relationnel, mais il répond à des besoins immédiats des personnes qui le suivent. Je ne recommande pas cette pratique, mais je reconnais que c'est la pratique courante.

Un index est une structure de données qui permet un accès rapide à quelques lignes d'une table, en fonction d'une description des colonnes de la table qui sont indexées. L'index est constitué de copies de certaines colonnes de la table, appelées clés d'index, entrecoupées de pointeurs vers les lignes de la table. Les pointeurs sont généralement cachés aux utilisateurs du SGBD. Les index fonctionnent en tandem avec l'optimiseur de requête. L'utilisateur spécifie dans SQL quelles données sont recherchées et l'optimiseur propose des stratégies d'index et d'autres stratégies pour traduire ce qui est recherché en une stratégie pour le trouver. Il existe une sorte de principe d'organisation, tel que le tri ou le hachage, qui permet d'utiliser un index pour les recherches rapides et certaines autres utilisations. Tout cela est interne au SGBD, une fois que le générateur de base de données a créé l'index ou déclaré la clé primaire.

Il est possible de créer des index qui n'ont rien à voir avec la clé primaire. Une clé primaire peut exister sans index, bien que ce soit généralement une très mauvaise idée.