私は次の移行を介して生成した多型参照を持つテーブルを持っている：私は、マイグレーションを実行したとき順序
def change
add_reference :table_name, :thing, polymorphic: true, index: true
end
それは次のように生成された：
add_index "workflow_engine_task_bases", ["thing_type", "thing_id"], name: "index_workflow_engine_task_bases_on_thing_type_and_thing_id", using: :btree
なぜ一番左の列がthing_typeですか？私には、あまり具体的でないため、これは最適ではないようです。
http://apidock.com/rails/v4.2.7/ActiveRecord/ConnectionAdapters/SchemaStatements/add_reference。
add_referenceのソースコードで
：それはちょうどtypeが先idのある配列からマッピングだ
add_index(table_name, polymorphic ? [type id].map{ |t| "#{ref_name}_#{t}" } : "#{ref_name}_id", index_options.is_a?(Hash) ? index_options : {}) if index_options
。なぜこのように設計されたのか分かりませんが、代わりにadd_indexを使用するほうが良いかもしれません。
add_index(:table, [:thing_id, :thing_type])
これは、デレクによってレールにcommit多型の関連付けのためのインデックスを生成するときに更新add_referenceがid前typeを使用することが前にあります。変更の正当化は以下に再現されています。マルチカラム・インデックスの最初の
利用型の列
add_referenceあなたはそれが多型の参照を追加するために を使用するときに、非常に親切マルチカラムインデックスを追加することができます。ただし、 インデックスの最初の列はid列です。これは理想よりも小さいです。[PostgreSQLのドキュメント] [1]と言う：
複数列のBツリーインデックスは、インデックスの列の任意のサブセットを伴う 問い合わせ条件で使用することができますが、インデックスが存在する場合に最も 効率的です先頭の（一番左の） 列の制約。
[MySQLのドキュメント] [2]言う：
MySQLは、インデックス内のすべての 列をテストするクエリ、またはクエリに複数列のインデックスを使用することができ、テストだけ最初の列、 最初の二つのその列、最初の3つの列などがあります。インデックス定義で正しい順序で列を と指定した場合、単一の 複合インデックスは、同じ テーブルで複数の種類のクエリを高速化できます。
多型の関係では、型列の方が、id列よりもインデックスの最初の列として有用な可能性が高くなります（ ）。つまり、私は よりIDのない型で照会する可能性が高く、idなしで照会するのはID です。
[1]：http://www.postgresql.org/docs/9.3/static/indexes-multicolumn.html
[2]：http://dev.mysql.com/doc/refman/5.0/en/multiple-column-indexes.html
私はほとんどのシナリオで考えて、この順序は意味があります。それは、typeとidまたはちょうどtypeを含むクエリでうまくいく1つのインデックスを持つことができます。
あなたのユースケースは、使用するデータベース、データセット、実行するクエリによって異なります。最善の方法は、プロダクションダンプで最も一般的なユースケースをプロファイルし、それに応じてインデックス戦略を選択することです。