2010-06-04 5 views
1

J'ai une question sur l'optimisation de base de données, l'indexation. Je table qui appelle les "projets" et je vais exécuter des requêtes comme ceci:Structure de l'index MySQL: index multiple ou simple?

commande Requêtes

SELECT * FROM projets où actif = 1 ORDER BY créé

SELECT * FROM projets où actifs = 1 ORDER BY project_deadtime

SELECT * FROM WHERE projets actifs = 1 ORDER BY project_allowedtime

Mon tableau Stuct ure Comme cette

id int (11) NO PRI NULL AUTO_INCREMENT employer_id int (11) NO MUL NULL
project_title varchar (100) NO MUL NULL
texte project_description NO NULL
project_budget int (11) NO NULL
project_allowedtime int (11) NO NULL
Date de project_deadtime NO NULL
créé datetime NO MUL NULL
tinyint active (1) NO MUL NULL

Quelles colonnes dois-je créer index et comment (index de colonne unique ou multiple?). Par exemple devrais-je utiliser & active-created_deadtime & active-project_allowedtime plusieurs index actifs ou un seul index actif suffit? Merci

EDIT: la table des projets aura un maximum de 1000-2000 lignes. La performance des requêtes SELECT est importante et environ% 90 des projets est actif.

+0

Environ combien de lignes votre tableau aura-t-il au maximum? En gros, quel sera le nombre maximum de projets actifs à un moment donné? La table des projets –

+0

aura un maximum de 1000-2000 lignes. La performance des requêtes SELECT est importante et environ% 90 des projets est actif. – mTuran

Répondre

3

Quelles requêtes seront utilisées le plus souvent? Combien de lignes y aura-t-il? Quelles requêtes doivent être les plus rapides? Courez-vous plus SELECT s ou plus INSERT s? Il y a beaucoup de considérations dans l'optimisation des performances d'une base de données.

Basé uniquement sur ce que vous avez posté, vous utilisez les colonnes suivantes seulement:

  1. actif
  2. créé
  3. project_deadtime
  4. project_allowedtime

Un index uniquement sur active ferait peu de bien - il réduirait probablement les résultats à environ la moitié.

Les autres colonnes sont chacune des indices potentiels. Si vous n'êtes pas concerné par les performances de INSERT s que la performance de SELECT s, je dirais que l'indice tous les trois, en donnant la priorité à la colonne susceptible de restreindre une requête au plus petit nombre de lignes:

  1. (créé, actif)
  2. (project_deadtime, actif)
  3. (project_allowedtime, actif)

Cela permettra à MySQL d'utiliser l'index si seule la première colonne est utilisée (par exemple, si seulement created est nécessaire) ou si les deux colonnes sont utilisées (pour affiner les résultats encore plus loin).

+0

La table des projets aura un maximum de 1000-2000 lignes. La performance des requêtes SELECT est importante et environ% 90 des projets est actif. – mTuran

3

Vous devez prendre en compte la sélectivité de l'index actif.

  • Si un très petit nombre de vos projets sont actifs à tout moment:

    (active) 
    
  • Si seulement un nombre relativement restreint de vos projets sont actifs à tout moment, mais la table est très grande:

    (active, created) 
    (active, project_deadtime) 
    (active, project_allowedtime) 
    
  • Si une grande partie des projets peuvent être actifs en même temps:

    (created) 
    (project_deadtime) 
    (project_allowedtime) 
    

Mise à jour: sur la base des nouvelles informations que vous avez fournies, j'aller avec la dernière option. Bien qu'avec une telle petite table le tri devrait être proche de l'instant même sans index. Une autre alternative est de modifier la troisième option pour qu'elle soit un indice de couverture.