Quand ajouter quels index dans une table dans Rails

J'ai une question sur la base de données Rails.

• Dois-je ajouter "index" à toutes les clés étrangères comme "xxx_id"?
• Dois-je ajouter "index" à la colonne "id" créée automatiquement?

• Dois-je ajouter "index (unique)" à la colonne "id" créée automatiquement?

• Si j'ajoute un index à deux clés étrangères à la fois ( add_index (:users, [:category, :state_id]), que se passe-t-il? En quoi est-ce différent de l'ajout de l'index pour chaque clé?

  class CreateUsers < ActiveRecord::Migration
    def self.up
      create_table :users do |t|
        t.string :name
        t.integer :category_id 
        t.integer :state_id
        t.string :email
        t.boolean :activated
        t.timestamps
      end
    # Do I need this? Is it meaningless to add the index to the primary key?
    # If so, do I need :unique => true ?
    add_index :users, :id 
    # I don't think I need ":unique => true here", right?
    add_index :users, :category_id # Should I need this?
    add_index :users, :state_id # Should I need this?
    # Are the above the same as the following?
    add_index (:users, [:category, :state_id])
    end
  end

Excellente réponse jusqu'à présent. Question supplémentaire.

• Je devrais ajouter "index avec unique" pour xxx_id, non?

Dois-je ajouter "index" à toutes les clés étrangères comme "xxx_id"?

Ce serait mieux, car cela accélère la recherche en tri dans cette colonne. Et les clés étrangères sont souvent recherchées.

Depuis la version 5 des rails, l'index sera créé automatiquement, pour plus d'informations, cliquez ici .

Dois-je ajouter "index" à la colonne "id" créée automatiquement?

Non, cela se fait déjà par rails

Dois-je ajouter "index (unique)" à la colonne "id" créée automatiquement?

Non, comme ci-dessus

Si j'ajoute un index à deux clés étrangères à la fois ( add_index (:users, [:category_id, :state_id]), que se passe-t-il? En quoi est-ce différent de l'ajout de l'index pour chaque clé?

Ensuite, l'index est un index combiné des deux colonnes. Cela n'a aucun sens, sauf si vous voulez toutes les entrées pour un category_id ET un state_id(cela ne devrait category_idpas être category) en même temps.

Un index comme celui-ci accélérerait la requête suivante:

# rails 2
User.find(:all, :conditions => { :state_id => some_id, :category_id => some_other_id })

# rails 3
User.where(:state_id => some_id, :category_id => some_other_id)

Où

add_index :users, :category_id
add_index :users, :state_id

accélérera ces demandes:

# rails 2+3
User.find_by_category_id(some_id)
User.find_by_state_id(some_other_id)

# or
# rails 2
User.find(:all, :conditions => {:category_id => some_id})
User.find(:all, :conditions => {:state_id => some_other_id})

# rails 3
User.where(:category_id => some_id)
User.where(:state_id => some_other_id)

Je devrais ajouter "index avec unique" pour xxx_id, non?

Non, car si vous faites cela, un seul utilisateur peut être dans une catégorie, mais la signification de la catégorie est que vous pouvez mettre plus d' utilisateurs dans une seule catégorie. Dans votre Usermodèle, vous avez quelque chose comme ça belongs_to :categoryet dans votre modèle de catégorie quelque chose comme has_many :users. Si vous avez une has_manyrelation, le foreign_keychamp ne doit pas être unique!

Pour des informations plus détaillées à ce sujet, vous devriez jeter un œil à la grande réponse de tadman .

L'indexation peut être une chose délicate et subtile, mais il existe des règles générales qui s'appliquent qui peuvent faciliter la détermination des éléments à utiliser.

La première chose à retenir est que les index peuvent fonctionner de plusieurs manières. Un index sur A, B, C fonctionne également pour A, B et simplement A, vous pouvez donc concevoir vos index pour qu'ils soient plus polyvalents si vous les commandez correctement. L'annuaire téléphonique est indexé sur le nom, le prénom, de sorte que vous pouvez rechercher facilement les personnes par leur nom de famille ou une combinaison de nom et prénom. Cependant, vous ne pouvez pas les rechercher directement par leur prénom. Vous auriez besoin d'un index séparé pour cela. Il en va de même pour le numéro de téléphone, que vous devrez également indexer.

Dans cet esprit, il y a beaucoup de choses qui dicteront comment vous créez des index:

• Si vous avez une paire de relations belongs_to- has_many, vous devez avoir un index sur la clé étrangère utilisée.
• Si vous commandez vos enregistrements et qu'il y en a un grand nombre qui seront paginés, vous devez ajouter cette colonne d'ordre à la fin de l'index.
• Si tu as un has_many :through relation, votre table de jointure doit avoir un index unique sur les deux propriétés impliquées dans la jointure en tant que clé composée.
• Si vous récupérez un enregistrement directement à l'aide d'un identifiant unique tel qu'un nom d'utilisateur ou une adresse e-mail, il doit s'agir d'un index unique.
• Si vous récupérez des ensembles d'enregistrements à partir d'une has_manyrelation à l'aide d'une étendue, assurez-vous qu'il existe un index qui inclut la has_manyclé étrangère et la colonne d'étendue dans cet ordre.

Le but des index est d'éliminer les redoutables opérations de «balayage de table» ou de «tri de fichiers» qui se produisent lorsque vos données ne sont pas indexées correctement.

En termes simples, examinez les requêtes générées par votre application et assurez-vous que les colonnes référencées dans WHEREou les HAVINGconditions et ORDER BYclauses sont représentées dans cet ordre.

• Toujours indexer les clés étrangères
• Indexez toujours les colonnes que vous classerez
• Tous les champs uniques (pour garantir l' unicité à un niveau de base de données migration Exemple:. add_index :users, :email, unique: true)
• Si vous commandez par deux choses, ou effectuez une recherche par deux choses, par exemple: order by [a, b]ou find where( a and b ), alors vous avez besoin d'un double index:

Exemple concret:

Si tu as:

default_scope :order => 'photos.created_at DESC, photos.version DESC'

Vous devez ajouter:

add_index :photos, [:created_at, :version]

Remarque: un index occupe de l'espace supplémentaire sur le disque et ralentit la création et la mise à jour de chaque enregistrement, car il doit reconstruire chaque index.

Crédit:

https://tomafro.net/2009/08/using-indexes-in-rails-choosing-additional-indexes , rails - created_at lorsque l'utilisateur pour la commande, devez-vous ajouter un index à la table? , et les réponses ci-dessus.