问题标签 [covering-index]

我有这张桌子：

我用 10 000 000 行填充此表。按日期重新分区是同质的

这是结果

=> 没有解释 3.6 秒，结果为 3000 行（大约）

如您所见，未使用索引，并且它不是 possible_keys 列的一部分！

具有覆盖索引方式的相同请求

结果：

=> 没有解释 2.8 秒，结果为 3000 行（大约）

为什么 MySQL 不能正确使用这个索引（日期）？？？

信息： - VM Server（我们的开发环境，我不知道硬件组成是什么） - MySQL 5.5.8

结果：

• 对于日期 2014-03-04 => 3134 行
• 总计（汇总）=> 7 875 488
• 表中有 2556 个不同的“日期”值

我以前从未听说过覆盖索引，只是偶然发现了它们。我正在阅读他们的这一页，上面写着..

“覆盖索引可以显着加快数据检索速度，但由于额外的键，它本身可能很大，这会减慢数据插入和更新速度。为了减少这种索引大小，一些系统允许将非键字段包含在索引中。非-key 字段本身不是索引排序的一部分，而仅包含在叶级别，从而允许覆盖索引具有较小的整体索引大小。”

所以我的问题是你怎么知道你的系统是否允许非关键字段包含在索引中？

Is it possible to use the CreateIndex syntax of EF Code First Migrations to create a Covering Index (*see below for what a Covering Index is).

For example I can create a simple index in a manual migration like so:

It has a final argument named "anonymous arguments" that specifies it can handle whatever the underlying provider supports - but it's not clear how I determine what that support would be. Is this possible or do I need to resort to flat SQL?

*A Covering Index is one where the RDB stores duplicated data in the leaf nodes, not just pointers to the main table. It's essentially a duplication of a table reordered by the columns in the index, containing just the columns most used in that type of search.

我有一个在多个表上执行连接的查询。我在表的外键上有非聚集索引，在主键上有聚集索引。在分析查询计划时，我发现查询优化器选择对所有表进行聚集索引扫描，或者在某些情况下结合非聚集索引扫描和键查找来获取其他非键列。为了解决这个问题，我在非聚集索引中包含（覆盖）了此查询中所需的非键列。因此，我可以看到非聚集索引搜索/扫描按预期执行。

现在我的问题是，如果我有其他查询需要许多其他非键列作为结果集的一部分，那么我最终可能会将所有列添加（包括）到非聚集索引中以提高所有查询的性能. 这是个好主意吗？

谢谢。

如何检查 MySQL 查询是否正在使用覆盖索引并仅从该索引中获取所需的所有数据？

据我所知，覆盖索引是应该包含 SELECT 语句中所有列的索引。如果是这样，如果我有如下查询怎么办：

我认为我不能将 SELECT 部分中的所有列都包含在覆盖索引中。如果是这样，我怎样才能提高这个查询的性能？

考虑一个包含以下字段的表：

请注意，字段名称具有唯一约束。

假设我想优化以下查询：

该name字段已经有一个索引（由于唯一性约束），但最好也为该字段设置一个覆盖索引value。

唯一约束只有一个索引，当我运行EXPLAIN命令时没有什么奇怪的事情发生：

现在如果我尝试添加一个覆盖索引，

它显示为查询的候选，但未被选中！

请注意，如果我删除唯一约束，

覆盖指数按预期工作：

那么如何使用覆盖索引并且仍然具有唯一约束？

我有一张表pings，里面有大约 1500 万行。我在 postgres 9.2.4 上。它具有的相关列是一个外键monitor_id、一个created_at时间戳和一个response_time表示毫秒的整数。这是确切的结构：

我想查询所有没有的响应时间NULL（90% 不会NULL，大约 10% 会NULL），具有特定的monitor_id，并且是在上个月创建的。我正在使用 ActiveRecord 进行查询，但最终结果如下所示：

这是一个非常基本的查询，但运行大约需要 2000 毫秒，这似乎相当慢。我假设索引会使它更快，但我尝试过的所有索引都不起作用，我假设这意味着我没有正确索引。

当我运行时EXPLAIN ANALYZE，这就是我得到的：

所以最后有一个索引monitor_id正在使用，但没有别的。我已经使用monitor_id,created_at和尝试了复合索引的各种排列和顺序response_time。我试过按created_at降序排列索引。我已经尝试使用response_time IS NOT NULL.

我没有尝试过使查询更快。您将如何优化和/或索引它？

我有一个网站，其中有一个活动源，类似于 Facebook 等社交网站有一个。它是一个“最新的优先”列表，描述了用户采取的行动。在生产中，该表中有大约 200k 个条目。

由于无论如何都会被问到，我将首先分享完整的表结构：

在优化这个表之前，我的查询有 5 个连接，我遇到了很慢的查询时间。我已经对所有这些数据进行了非规范化，因此不再存在单个连接。所以表和查询是平的。

正如您在表格设计中看到的，有一个“事件”字段，它是一个枚举，包含几十个可能的值。在整个站点中，我根据特定事件类型显示活动提要。通常，该查询如下所示：

此查询的作用是在总集中查找与 $events 中传递的任何事件匹配的最新 30 个条目，这些事件可以是多个。

由于删除了连接并在大多数字段上都有索引，我希望这会表现得很好，但事实并非如此。在 200k 条目上，它仍然需要 3 秒多，我不明白为什么。

关于解决方案，我知道我可以归档旧条目或按事件类型对表进行分区，但这会对代码产生相当大的影响，我首先想了解为什么上述内容如此缓慢。

作为临时解决方法，我现在正在这样做：

这样做的目的是将基本集限制为仅搜索最新的 1000 个条目，希望并猜测有 30 个条目可用于我传入的过滤器。虽然它不是很健壮。它不适用于更罕见的事件，并且会带来分页问题。

因此，我首先想了解为什么我的初始查询很慢的根本原因，这与我的预期相反。

编辑：我被要求分享执行计划。这是测试查询：

执行计划：

我不知道如何阅读上面的内容，但我知道 sort 子句似乎真的杀死了这个查询。使用这种排序，需要 4.3 秒，没有 0.03 秒。

我试图理解为什么 MySQL 不使用完整索引来回答查询。让我解释。我通过 MySQL 版本 5.1.73-1 (Debian) 使用 imdb 数据库。我在movie_info_idx 表上创建并索引“itid_inf25_mid_ndx”，其中包含列（info_type_id、info(25)、movie_id）。info_type_id 和movie_id 列是整数（NOT NULL），info 是TEXT 类型，因此每个索引条目占用4+27+4 = 35 个字节。句子的输出：

显示这些值：

选择类型 = 简单；表=电影信息IDX；类型=范围；可能键= itid_inf25_mid_ndx；键= itid_inf25_mid_ndx；key_len = 31; 参考=空；行 = 841; 额外 = “使用地点”

key_len 列和额外列中没有“使用索引”通知仅使用索引中的总和 4+27 = 31 个字节的列 (info_type_id,info(25))。我想知道为什么优化器不使用索引中的movie_id 列来访问SELECT 子句中的movie_id？似乎优化器将访问基表movie_info_idx 以获取我要列出的movie_id 值。为什么？。

预先感谢您的回复。