创建包含所有列的索引是否合理？

Question

我们有一个列的表

 ID
 OtherTableId
 DataA
 DataB
 DataC
 DataD

当我们需要所有列时，在OtherTableID INCLUDE (ID, DataA, DataB, DataC, DataD)上创建索引是有意义的吗?还是仅仅在(OtherTableID)上创建索引就足够了？

我知道包含索引会有效地重复表的大小，但是它会提高性能吗？

查询是：

select * from Table Where OtherTableID = ?

Answer 1

如果

• 查询使用所有这些字段，
• 排序顺序需要与聚集索引的顺序不同，并且
• 不能更改聚集索引，

具有不同列顺序的附加(覆盖)索引可能适用于您。与任何与索引相关的索引一样，更多(更宽)的索引意味着更慢的写入/更新性能。如果你要把表的大小增加一倍，这一点尤其正确。

如果只是索引OtherTableId而不包括其他列，则会得到一个较小的索引，但您的查询可能最终只使用聚集索引和昂贵的扫描或排序操作符，或者使用来自非聚集索引的键查找，如果每次只查询几行，但如果扫描整个表则会造成灾难性的后果。

这是一般的建议。有关详细信息，请编辑您的问题以包括查询、表定义和查询计划。

Answer 2

关于这件事不是有很多信息吗？不过，我在MySQL上学习了SQL，并将其打包到Server中，因此，开放源码文档可能更好。

您需要知道的基本问题是索引是用于什么的。然后你就会知道你是否“应该”使用它们。

基本上，问问自己是否将在除SQL语句的SELECT子句之外的任何地方使用列。如果是，请考虑索引它。如果不是，那就少得多的理由了。据我所知，SELECT中列出的列比JOIN、WHERE、GROUP、ORDER等列“昂贵”得多。

如果是的话，下一个问题就更难回答了，因为正如其他答案所提到的，索引是有成本和好处的。我认为索引根据索引列的大小增加表大小是不正确的。我相信，规模的增加与指数的基数成正比。但无论如何，它确实会增加插入时间。因此，如果您的表很少被修改，并且主要是从。无论如何，添加所有可能的索引“以防万一”。

但是，如果表经常被写入，请更加小心。同样，我的大部分知识来自MySQL，但我相信这些知识也适用于这里。

1. 在MySQL中，或者在Server中，复合索引中的第一列不需要自己的单独索引。
2. 复合索引中列的顺序很重要。它应该与您声明中使用的命令相匹配。
3. 如果很少使用查询，那么添加索引以加快查询速度的成本可能不值得获得很小的好处。
4. 如果查询经常被使用并且表很大，那么一定要考虑索引以加快它的速度。

MySQL和Server都允许您查看查询执行计划。您可以使用它来帮助确定要索引的列(使用Google查找更多索引)

MySQL有一个“慢速查询日志”，我相信Server也有类似的功能，可以帮助您确定哪些查询耗时太长(Google )

Answer 3

下面是一个非常常见的2列索引，包含两个索引，每个索引都包含所有2列：http://mysql.rjweb.org/doc.php/index_烹饪书_mysql#many_至_许多_映射_表格

这是一个多对多映射表。它有两个in，用于连接两个表，这两个表处于多到多的关系中。

但这是个特例。

这是另一个特例。你知道什么是“覆盖”指数吗？它包含SELECT中提到的所有列。但是仅仅有一个覆盖指数并不比简单地拥有表本身更好。不过，..。如果覆盖索引的开头包含对优化WHERE有用的列(S)，而其余的列被加进去使其成为“覆盖”，那么就对了--您有一个具有两个优点的索引--帮助WHERE，而不必点击数据，因为所需的所有内容都在索引中。警告:索引中有超过5列是“不明智的”。