问题标签 [covering-index]

我正在我的数据库中运行一些查询，并希望提高性能并创建了一些索引，但我仍然认为响应时间很棒，所以我想看看我是否可以创建一个更好或另一个索引来提高速度。

我认为具有最大瓶颈的表的架构如下所示：

有趣的是包含日期（例如 2010-05-20）的SDD属性，在我的查询中，我进行了这样的范围搜索： SDD >= '2010-05-03' 和 SDD < '2010-05-08'

我拥有的确实提高了性能的索引是

问题是，当我进行 2010-05-03 和 2010-06-04 等距离很远的范围搜索时，执行查询大约需要 6-10 秒，我真的很想调整它。

我在 SDD 上尝试了几个索引，甚至一个集群索引，但到目前为止我得到的最好结果是上面的索引。

任何建议将不胜感激。

真挚地

梅斯蒂卡

SQL Server 2005 包含“覆盖索引”功能，它允许我们选择多个非键列包含到现有的非聚集索引中。

例如，我有以下列：

这里有两种情况：

• EmployeeID是具有聚集索引的主键，其余列（DepartmentID, DesignationID, BranchID）被视为非聚集索引（复合索引）。

• EmployeeID是具有聚集索引的主键，并且DepartmentID是具有 的非聚集索引 DesignationID，是非聚集索引BranchID的“包含列”。

以上两者有什么区别？如果两者相同，引入“覆盖指数”概念有什么新意？

我有一个关于在 SQL Server（或任何 RDBMS）中建立索引的最佳实践的问题。取下表：

ProfileID连接到一个Profile表。对于每个配置文件，每个配置文件都Text必须是唯一的。因此，我在两列上都放了一个主封面键。美好的。

但是，我也希望能够通过ProfileID. 所以我也放了一个索引ProfileID。

这意味着我有一个重叠的索引。我不知道这是否完全浪费，因为已经有一个封面索引，或者它是否正确，因为封面索引将是两列的哈希（或者我误解了封面索引）？

编辑：

我按顺序创建了索引(ProfileID, Text)。如果为了论证的缘故，有 3 列 A、B 和 C，它们在所有 3 中都有一个覆盖索引。只有当我们针对“A”或“A、B 和 C”进行查询时它才会受益，但不是“B”，还是“C”，还是“B 和 C”？

我正在使用 SQL Server 2008 Express。在有问题的数据库中，只有一个模式：dbo。

如果我运行以下脚本：

...它执行正常，但是当我进入数据库图并查看该表的索引时，我看不到索引。此外，“包含”字段始终显示为灰色，即使我指定了非聚集索引（因此我使用了脚本）。

有任何想法吗？

(ExternalProductId, SourceId, AnotherField) 上有一个索引。解释显示使用了索引。这打印在说明的“额外”列中：

当我运行查询时，我通过 SHOW PROCESSLIST 看到：

我可以调整这个查询以在索引上工作吗？我也不介意我得到的结果是否因为其他进程同时在此表上工作而稍微不准确 - 我可以更改隔离级别以提高查询的性能吗？

是否有为 MySQL 中的表创建覆盖索引的标准顺序？这意味着如果我的查询具有 where 子句、order by 和 select 语句中的字段，我将按什么顺序将字段添加到索引以正确创建覆盖索引？

使用 SQL2008，我试图找出一个有效的查询来查找日期最接近特定目标日期的行。

有明显低效的解决方案（例如使用ABS 和 DATEDIFF的表扫描），我没有费心去看，因为我的表已经有一个覆盖索引，其中日期是第一列。在准确确定最近的行之前，我可以使用该索引缩小结果范围。

从理论上讲，我应该能够使用单个索引查找来满足查询，然后从该索引中顺序提取 2 行数据。

但到目前为止，我一直无法找到比这个更优化的解决方案：

这很快（在下面的测试模式中进行 4 次逻辑读取，在我的真实表中进行 9 次逻辑读取），但它仍然是 2 次扫描计数的解决方案。有没有更有效的解决方案，只命中这个索引一次？

还是我现有的解决方案“足够好”，因为第二次索引搜索将拉取第一次搜索访问的缓存页面，这意味着它会非常快，以至于进一步优化（即使可能）将产生最小的实际性能改进？

这是架构和一些示例数据。两者都是从我的实际模式中简化的，尽管生成的查询计划与我更复杂的表相同：

我有一个国家文件，看起来像这样：

为了仅在查询时触摸索引：

我添加了以下索引：

据我了解，查询现在应该只触及索引。但是， .explain() 告诉我查询根本没有使用任何索引：

我认为原因可能是完整的数据库将被输出（247 个国家），但这对我来说没有任何意义。当国家/地区在索引中可用时，应该使用索引，对吗？

有人有想法吗？

干杯

这是一个关于索引优化理论的漫长而复杂的问题。这不是家庭作业，尽管我是在 Microsoft 70-432 的示例考试中第一次接触到这个问题。最初的问题是关于一般查询优化，但后来我发现了我无法解释的这种特殊行为。

一、表格：

现在，一个聚集索引，以及两个用于测试的索引：

我还向表中添加了一些随机测试数据 - 100000 行。Invoice_id、Customer_id 和 Amount_total 分别收到它们自己的随机值（范围 1000-9999），Invoice_date 收到 GETDATE() 加上随机秒数（范围 1000-9999）。我可以提供我使用的实际例程，但不认为具体是相关的。

最后，查询：

显然，查询的第一步将是非聚集索引扫描。无论使用哪个索引，第一步都将返回相同数量的索引行。使用“原始”索引，下一步将是通过聚集索引进行查找以检索 Invoice_date，然后是两个集合之间的内部 JOIN。使用“优化”索引，该字段包含在索引叶中，因此规划器直接返回结果。

哪个索引可以加快执行速度，为什么？

在以下查询中

如果我有 2 个单独的索引，一个在col3上，另一个在col4上，其中哪一个将用于此查询？

我在某处读到，对于查询中的每个表，只使用一个索引。这是否意味着查询无法同时使用两个索引？

其次，如果我同时使用col3和col4创建了一个复合索引，但在WHERE子句中只使用col3会不会降低性能？例子：

最后，在所有情况下都使用覆盖索引更好吗？MISAM 和 innodb 存储引擎有区别吗？