在ActiveRecord中，有两种方法可以为多个列声明索引:
add_index :classifications, [:species, :family, :trivial_names]
add_index :classifications, :species add_index :classifications, :family add_index :classifications, :trivial_names
第一种方法和第二种方法有什么区别吗？如果是的话，我应该什么时候使用第一个，什么时候使用第二个？
你正在比较一个综合指数和一组独立指数.它们只是不同而已.
可以这样想:复合索引可以在一组嵌套字段中快速查找第一个字段，然后快速查找第二个字段within ONLY the records already selected by the first field，然后快速查找第三个字段——同样，只在前两个索引 Select 的记录中.
让我们举个例子.在使用索引的if万条记录(如果内存可用)中，数据库引擎最多只需20个步骤就可以找到唯一值.无论你使用的是复合索引还是独立索引，这都是正确的——但只适用于第一个字段(在你的示例中是"物种"，尽管我认为你需要家族、物种，然后是通用名称).
现在，假设第一个字段值有100000条匹配记录.如果只有一个索引，那么这些记录中的任何查找都将需要100000个步骤:第一个索引检索到的每个记录一个步骤.这是因为第二个索引将不被使用(在大多数数据库中——这有点简化)，必须使用蛮力匹配.
如果你有一个composite index，那么你的搜索速度要快得多，因为你的第二个字段搜索将有一个索引within作为第一组值.在这种情况下，在字段1的composite index000个匹配中，只需不超过17个步骤就可以获得字段2的第一个匹配值(以10万为基数的日志(log)2).
因此:在一个包含1000000条记录的数据库中，需要使用3个嵌套字段上的复合索引来查找唯一记录，其中第一个字段检索100000条记录，第二个字段检索10000=20+17+14=51个步骤.
在相同条件下，仅独立指数=20+100000+10000=110020步所需的步骤.
差别很大吧？
现在，don't个疯狂的综合指数随处可见.首先，它们的插入和更新成本很高.其次，只有当您真正在嵌套数据之间进行搜索时，才会使用它们(例如，我在为给定日期范围内的客户端登录提取数据时使用它们).此外，如果您使用的是相对较小的数据集，那么它们也不值得.
最后，判断数据库文档.如今，数据库在部署索引方面已经变得极其复杂，我上面描述的Database 101场景可能在某些情况下并不适用(尽管我总是像这样开发，以便知道我得到了什么).