索引两列表的所有字段答案

【问题标题】：Indexing all field of two columns table索引两列表的所有字段
【发布时间】：2012-10-15 17:42:54
【问题描述】：

我有一个表/模式，其中包含 DateTime 的 day 和 Integer 的 user_id 两列。知道我把两列都编入索引了。

考虑到索引使用的额外空间的很大一部分并且只有两列，从索引中获得的性能改进是否值得？你如何为他们辩护？

如果我使用 MongoDB 或 MySQL，这有何不同？

【问题讨论】：

理由来自查询。这真的归结为索引如何工作以及为什么它使查询更快的基本原理，进一步阅读的一点点：stackoverflow.com/questions/1108/… MySQL 和 MongoDB 之间的区别在于它们如何构造索引和其他内部内容（和空间）你不会在外面注意到的。

标签： mysql mongodb indexing database-design database

【解决方案1】：

如果行数很少，您可能看不到索引的显着改进。如果有很多行，您可能会看到很大的改进。

好处是您不必猜测，也不必为 few 和 many 在实践中的含义而苦恼。每个现代 SQL dbms 都包含一些测量 SELECT 语句性能的方法。这包括 MySQL。

【讨论】：

【解决方案2】：

从索引中获得的性能改进值得吗

取决于您打算运行的查询。

如果你有类似的东西：WHERE day = ...，那么你需要一个前沿包含day的索引。如果使用得当，索引可以将查询速度提高许多数量级，尤其是在大型数据集上。
OTOH，每增加一个索引都会消耗空间/缓存和 INSERT/UPDATE/DELETE 性能。

最后，我建议您衡量真实的数据量并得出自己的结论。

顺便说一句，如果您使用的是 InnoDB，那么您的表是 clustered（另请参见：Understanding InnoDB clustered indexes）并且整个表有效地存储在主索引中。聚簇表中的二级索引包含 PK 字段的副本，在这种情况下（我假设）是 user_id。由于我们在表中只有两个字段，{day} 上的二级索引也将覆盖user_id，避免在聚集表中可能发生的双重查找。实际上，无论您访问其中哪一个（这很好），您最终都会得到两个独立（但同步）的 B 树和一个 index-only scan。当然，您可以在 {day, user_id} 上显式地创建一个复合索引，而不仅仅是 {day}，以获得非常相似的效果。

【讨论】：