Les colonnes font généralement de bons index?

Indices peuvent jouer un rôle important dans l'optimisation de la requête et de la recherche les résultats rapidement sur les tables. C'est donc l'étape la plus importante pour sélectionner les colonnes à être indexé. Il existe deux principaux lieux où l'on peut envisager d'indexation: les colonnes référencées dans la clause where et les colonnes utilisées dans les clauses JOIN. Bref, ces colonnes doivent être indexés en fonction de qui vous êtes nécessaire à la recherche des documents particuliers. Supposons, nous avons une table nommée acheteurs où la requête SELECT utilise les index comme ci-dessous:

SELECT
 buyer_id /* no need to index */
FROM buyers
WHERE first_name='Tariq' /* consider to use index */
AND last_name='Iqbal'   /* consider to use index */

Depuis "buyer_id" est référencé dans la partie SELECT, MySQL de ne pas utiliser de limiter les choisi de lignes. Par conséquent, il n'y a pas besoin de l'indexer. Ci-dessous est un autre exemple un peu différent de ci-dessus, on:

SELECT
 buyers.buyer_id, /* no need to index */
 country.name    /* no need to index */
FROM buyers LEFT JOIN country
ON buyers.country_id=country.country_id /* consider to use index */
WHERE
 first_name='Tariq' /* consider to use index */
AND
 last_name='Iqbal' /* consider to use index */

Selon les au-dessus des requêtes first_name, last_name les colonnes peuvent être indexés comme ils sont situés dans la clause where. Aussi un champ supplémentaire, country_id from pays de table, peuvent être considérés pour l'indexation, car il est dans une clause de JOINTURE. Afin d'indexation peut être considéré comme sur tous les champs dans la clause where ou d'une clause de JOINTURE.

La liste suivante propose également quelques conseils que vous devez toujours garder à l'esprit lorsque l'intention de créer des index dans vos tables:

• Seul indice pour les colonnes qui sont nécessaires dans les clauses where et ORDER BY. L'indexation des colonnes en abondance va entraîner certains inconvénients.
• Essayer de prendre avantage de l'indice de "préfixe" ou "multi-colonnes d'index" de MySQL. Si vous créez un index comme INDICE de(prenom, nom), de ne pas créer d'INDEX(prenom). Cependant, l'indice de "préfixe" ou "multi-colonnes de l'index" n'est pas recommandé dans tous les cas de recherche.
• Utiliser l'attribut not NULL pour les colonnes qui vous compte de l'indexation, de sorte que les valeurs NULL ne seront jamais enregistrés.
• Utiliser l'option --log-long-format de l'option journal des requêtes qui n'utilisent pas d'index. De cette façon, vous pouvez examiner ce fichier journal et d'ajuster vos requêtes en conséquence.
• L'EXPLIQUER instruction permet de vous révéler comment MySQL va exécuter une requête. Il montre comment et dans quel ordre les tables sont jointes. Cela peut être très utile pour déterminer comment écrire des requêtes optimisées, et si les colonnes sont nécessaires pour être indexé.

Mise À Jour (23 Feb'15):

Un index (bon/mauvais) augmente d'insertion et de temps de mise à jour.

En fonction de votre index (nombre d'index et le type), le résultat est recherché. Si votre temps de recherche va augmenter en raison de l'indexation puis c'est un mauvais indice.

Probablement dans un livre, "Page d'Index" aurait pu être le début d'un chapitre de la page, rubrique numéro de la page commence, également sous la rubrique page de démarrage. Quelques précisions en page d'Index d'aide, mais plus détaillée de l'indice pourrait vous confondre ou vous effrayer. Les index sont également d'avoir de la mémoire.

La sélection d'Index doit être sage. Gardez à l'esprit de ne pas toutes les colonnes nécessiterait d'index.

Tout dépend sur quelles requêtes vous attendons à poser sur les tables. Si vous demandez pour toutes les lignes avec une certaine valeur pour la colonne X, vous devrez faire un full table scan si un index ne peut pas être utilisé.

Index sera utile si:

• La ou les colonnes d'un haut degré d'unicité
• Vous avez souvent besoin de regarder pour une certaine valeur ou un intervalle de valeurs pour
  la colonne.

Ils ne seront pas utiles si:

• Vous sélectionnez un grand % (>10 à 20%) de lignes de la table
• Supplémentaires d'utilisation de l'espace est un problème
• Vous voulez maximiser la performance de l'insert. Chaque index sur une table réduit insérer et mettre à jour les performances, car ils doivent être mis à jour chaque fois que des modifications de données.

Colonnes de clé primaire sont généralement idéal pour l'indexation, parce qu'ils sont uniques et sont souvent utilisés pour la recherche de lignes.

Toute colonne qui va être régulièrement utilisé pour extraire des données à partir de la table doit être indexé.

Cela comprend:
les clés étrangères -

select * from tblOrder where status_id=:v_outstanding

descriptif des champs -

select * from tblCust where Surname like "O'Brian%"

Les colonnes n'ont pas besoin d'être unique. En fait, vous pouvez obtenir de très bonnes performances à partir d'un index binaire lors de la recherche pour les exceptions.

select * from tblOrder where paidYN='N'

Colonne GUID n'est pas le meilleur candidat pour l'indexation. Les index sont les mieux adaptés pour les colonnes avec un type de données qui peut être donné un certain ordre significatif, c'est à dire triés (entier, la date, etc).

Il n'a pas d'importance si les données dans une colonne est généralement à la hausse. Si vous créez un index sur la colonne, l'indice de créer sa propre structure de données qui permet de référencer les articles réels dans votre table sans se soucier stockée ordre (un index non-cluster). Par exemple, une recherche binaire peut être réalisée sur votre indice de structure de données pour fournir une récupération rapide.

Il est également possible de créer un index cluster" qui sera physiquement modifier l'ordre de vos données. Cependant, vous ne pouvez avoir un de ces par table, alors que vous pouvez avoir plusieurs index non cluster.

Types de données numériques qui sont ordonnés dans l'ordre croissant ou décroissant, sont de bons indices pour de multiples raisons. D'abord, les chiffres sont généralement plus rapides à évaluer que des chaînes de caractères (varchar, char, nvarchar, etc). Deuxièmement, si vos valeurs ne sont pas commandés, les lignes et/ou les pages doivent être mélangées à mettre à jour votre index. C'est une charge supplémentaire.

Si vous utilisez SQL Server 2005 et mis sur l'utilisation de uniqueidentifiers (guid), et n'ont PAS besoin qu'ils soient de nature aléatoire, découvrez le séquentiel de type uniqueidentifier.

Enfin, si on parle d'index en cluster, vous parlez de la sorte de la physique des données. Si vous avez une chaîne de caractères comme votre index cluster, qui pourrait devenir laid.

L'ol " règle du pouce a été colonnes qui sont beaucoup utilisés dans le where, ORDER BY, et les clauses GROUP BY, ou l'un semblait être utilisés dans les jointures fréquemment. Gardez à l'esprit que je suis se référant à l'index, PAS de Clé Primaire

De ne pas donner un "vanille-ish" réponse, mais cela dépend vraiment de la façon dont vous accédez à des données