问题标签 [covering-index]

这是“高性能 MySQL 3rd”的示例。

这本书说MySQL不能执行如下LIKE。

MySQL 无法在索引中执行 LIKE 操作。这是低级存储引擎 API 的限制，在 MySQL 5.5 及更早版本中，它只允许在索引操作中进行简单的比较（例如相等、不等和大于）。MySQL 可以在索引中执行前缀匹配 LIKE 模式，因为它可以将它们转换为简单的比较，但是查询中的前导通配符使存储引擎无法评估匹配。因此，MySQL 服务器本身必须获取并匹配行的值，而不是索引的值。

在那之后，本书给出了“延迟加入”的改进。

即使 (actor, title, prod_id) 是“覆盖索引”，MySQL 也无法在索引中执行 LIKE。

我感到很困惑！

我有一个Couchbase(4.5)存储桶my-data。存储桶的简要概述如下。

文件结构

指数

我在存储桶中也有一个索引，如下所示。

我需要获取一些文档 ID，并希望使用上面给出的索引。另外，我希望结果被索引覆盖。

问题是当我在 where 子句中使用dayIds字段时，查询没有被覆盖。

以下是我尝试过的查询及其解释

Query-1（在 where 子句中使用 dayIds 数组）

解释-1

但是当我从 where 子句中删除数组时

查询 -2（where 子句中没有 dayIds 数组）

解释-2

为什么在 where 子句中使用 dayIds 数组时无法获取索引覆盖？

我正在尝试通过使用索引来优化对 SQLite 数据库的简单查询的性能。例如，表有 5M 行，5 列；该SELECT语句是拾取所有列，该WHERE语句仅检查 2 列。但是，除非我在多列索引中拥有所有列，否则查询的性能比没有任何索引时要差。

我是否错误地索引了列，或者在选择所有列时，我是否应该将所有列都包含在索引中以提高性能？

在每种情况下 # 是我在硬盘中创建 SQLite 数据库时得到的结果。但是，由于某种原因，使用该':memory:'模式使得所有索引案例都比没有索引更快。

我看到了描述覆盖索引的文档：

覆盖索引包含查询检索到的所有列
的索引。

这是否意味着覆盖索引是一个特定的索引？

我认为覆盖指数是一种现象。

如果我按照文档的描述，那么请看下面的sql语句：

idx_name_age是第一个语句中的覆盖索引，第二个不是。

所以我认为：覆盖指数是一种现象而不是指数。

覆盖索引是 InnoDB 中索引的一种特殊情况，其中查询的所有必需字段都包含在索引中，如本博客所述https://blog.toadworld.com/2017/04/06/speed-up- your-queries-using-the-covering-index-in-mysql。

但是，我遇到了一个情况，当 SELECT 和 WHERE 只包含索引列或主键时，没有使用覆盖索引。

MySQL 版本：5.7.27

示例表：

行数：300024

索引：

可以看出，SELECT 子句中的first_nameandlast_name是索引列，而emp_noWHERE 子句中的 是主键。但是，执行计划显示结果行是从主索引树中检索的。

在我看来，它应该扫描二级索引树，并过滤结果emp_no < '10010'，其中使用了覆盖索引。

编辑

此外，我看到在 MySQL 5.7.21 下同样的情况下使用了覆盖索引。

索引：

行数：8204

SQL：

结果：

我完全被这个弄糊涂了。我向 SQL Server 2017 表添加了覆盖索引，但我的集成测试失败了。

下面是一些简单的 SQL 来说明问题：

创建索引是为了解决其他地方的另一个问题，但失败的测试让我看到了这段代码。

通过尝试创建一个示例来重现问题，我可以看到，对于此代码，添加IsDeleted到覆盖索引可以解决问题，但这不是我所期望的。

由于测试突出了这个问题，我将添加IsDeleted到覆盖索引中。

我的问题是为什么 SQL 中断了，我如何预测还有什么可能会中断，因为只有我们的一些代码具有集成测试？

我正在努力将客户端与数据同步，以实现最终的一致性。服务器将发布数据库 ID 和行版本/时间戳的列表。然后，客户端将请求版本号不正确的数据。数据不一致的主要原因是代理节点之间的网络问题、裂脑等。

当我从表中读取数据时，我根据不是主键的谓词请求数据。我迭代可用区域以读取每个区域的数据。这是我的选择：

由于这会导致每个查询都进行索引扫描，我想知道我的 RegionId 列上是否有一个非聚集索引，并在该索引中包含选定的列：

VersionTimestamp是 rowversion/timestamp 列，并且当然会在更新行时更改，所以我想知道在索引中包含此列是否是一个糟糕的设计选择，因为它需要在每次插入/更新时更新/删除？

由于这将导致n次索引扫描，而不是n次索引搜索，因此最好读取一次所有数据，然后按 regionId 分组并填充 regionId 没有任何数据的行的空列表。

现实生活中的场景要复杂一些，因为还必须查询表关系。我还没有考虑在我的版本查询中包含一对多关系。

这主要是为了更好地理解覆盖索引的影响并弄清楚如何更好地使用它们。由于无论如何我都会从表中读取所有数据，因此一次加载它们可能更便宜。但是，从上面的查询中读取它们，它使我的代码对于这个简单的无关系示例来说更加清晰。

编辑： 备选方案 2 想到的另一个选项是在RegionId上创建一个覆盖索引，并包含我的主键（DatabaseId）。

然后是一个新查询，我在其中选择所需的列 WHERE DatabaseId IN(list, of, databaseId)

对于当前场景，表中最多只有数千行，而不是数百万行。两个 (x n ) 查询的网络流量很可能超过使用索引的好处，并且是过早的优化。

PostgreSQL 中以下两个索引有什么区别：

和

给定下表car_year的汽车型号年份：

我想有一个“最早的制造商模型”的覆盖指数。我的解决方案是创建一个物化视图：

然后是覆盖索引：

有用！但是物化视图是无用的（对我来说），因为我只会使用覆盖索引。我是否缺少更优雅的解决方案，或者我不知道的（Postgre）SQL 功能？

假设我有三列，A、B、C。它们分别具有x、y 和 z 可能值的范围。

所有三列上的索引是否具有与 x * y * z 成比例的大小？