问题标签 [full-table-scan]

我在 Hive 0.13 中有一个大表 - 它每天大约有 250 GB 的数据。因此，每小时大约有 10 GB 的数据。我有一个 BI 工具，它希望每天或每小时访问该表的数据，为此我需要测试 BI 工具将生成并在 Hive 上运行的查询。

其中一个查询，当 BI 用于昨天的每日数据时，如下所示：

我的表在 MY_TABLE 中的 Hive 中，而 YYYY、MM 和 DD 是 MY_TABLE 中的分区列。它已经以 ORC 格式存储。

上面的查询运行了很长时间，当我看到 EXPLAIN EXTENDED 输出时，我清楚地看到它正在执行 MY_TABLE 的 FULL TABLE SCAN，而与过滤条件无关。

我们怎样才能避免这个问题？

好心提醒。

再次注意：Hive 版本是 0.13。我们正在进行升级。

谢谢，

净土

笔记：

此处提供的解决方案（为什么此查询不发生分区消除？）不适用于我的情况，因为我使用的是 Hive 0.13，而 CURRENT_DATE 函数仅在 Hive 版本 1.+ 之后可用。

我有以下 MySql 表（只有 845 行）：

（你可以看到我有很多索引，以防万一）。

我执行以下自联接查询：

这会产生以下解释：

EXPLAIN 表明 MySql 选择不使用索引，我不明白为什么。表定义显示所有相关列都已编入索引。

在更大的查询（500 万行，14 个表）的范围内，这部分被证明是一个巨大的瓶颈。任何意见，将不胜感激。

谢谢，

我们的一个查询有一点问题，该查询是在 .Net (4.5) 应用程序中通过 .Net (4.5) 执行的System.Data.SqlClient.SqlCommand。

问题是，查询将执行非常慢的表扫描。所以执行计划在这里显示了 Table-Scan

截屏：

细节：

因此文本显示，对Termine.Datum和Termine.EndDatum的过滤器会导致 Table-Scan。但是为什么 SQL-Server 会忽略索引呢？Termine.Datum和Termine.EndDatum上有两个索引。我们还尝试结合Datum和EndDatum添加第三个。

索引都是非聚集索引，两个字段都是DateTime。

select *from REPT_AIR_PRY_HY1 RAP where (RAP.DATE_OF_ISSUE) BETWEEN "2017-10-01" AND DATE_ADD("2017-10-31", INTERVAL 1 DAY)

这个查询的解释计划给了我337243 但这些日期之间的数据只有55209，甚至在列 DATE_OF_ISSUE 上创建了索引。那么，为什么它要扫描整个表呢？提前致谢

简介：有什么方法可以提高对 InnoDB 表的表扫描性能？

请不要建议添加索引以避免表扫描。（见下文）

innodb_buffer_pool_size 占服务器内存的 75% (48 GB/64GB) 如果有任何改变，我正在使用最新版本的 Percona (5.7.19)

更长：我们有 600Gb 的最近时间序列数据（我们汇总和删除旧数据）分布在 50-60 个表中。因此，其中大部分是定期查询的“活动”数据。这些表有点大（400 多个数字列），许多查询针对其中的一些列（令人担忧）运行，这就是为什么添加索引是不切实际的（因为我们必须添加几十个）。每天对最大的表进行分区。

我完全意识到这是一个应用程序/表设计问题，而不是“服务器调优”问题。我们目前正在努力显着改变这些表的设计和查询方式，但必须维护现有系统直到发生这种情况，所以我正在寻找一种方法来稍微改进一下，为我们争取一点时间。

我们最近拆分了这个系统，并将其中的一部分移到了新服务器上。它以前使用 MyISAM，我们尝试迁移到 TokuDB，这似乎很合适，但遇到了一些奇怪的问题。我们切换到 InnoDB，但性能真的很差。我的印象是 MyISAM 在表扫描方面更好，这就是为什么，除非有更好的选择，否则我们会回到它，直到新系统到位。

更新

所有表都具有几乎相同的结构：-timestamp -主键（varchar(20) 字段）-大约 15 个不同类型的字段，表示可以过滤的其他辅助属性（首先带有适当的索引标准）-然后大约几百个措施（浮动），在 200-400 之间。

在不改变结构本身的情况下，我已经尽可能地修剪了行长。主键曾经是 varchar(100)，所有度量值都曾经是双精度数，许多次要属性的数据类型都发生了变化。

升级硬件并不是一个真正的选择。

仅使用我需要的一组列创建小表将有助于一些流程执行得更快。但代价是首先使用表扫描创建该表并复制数据。也许如果我将它创建为内存表。据我估计，缓冲池需要几 GB 的空间。还有一些聚合过程会定期从主表中读取尽可能多的数据，并且它们需要所有列。

不幸的是，在我计划在下一个版本中解决的那些查询中有很多重复的工作。每次插入一些行（每半小时）时，警报和聚合过程基本上都会重新处理一整天的数据，而不仅仅是处理新的/更改的数据。

就像我说的，较大的表是分区的，所以通常是对每日分区而不是整个表进行扫描，这是一个小小的安慰。

实现一个系统将其保存在数据库之外的内存中是可行的，但这将需要对遗留系统和开发工作进行大量更改。还不如把时间花在更好的设计上。

事实上，对于与 MyISAM 相同的数据，InnoDB 表要大得多（在我的情况下是 2-3 倍），这确实阻碍了性能。

MERGE INTO这是关于 Oracle RDBMS 12c 上具有特定场景的 Oracle 语句的一般问题。

每日数据将被加载到StagingTableA- 大约 10m 行。这将是MERGEd INTO TableA。 TableA将在 0 到 10m 行之间变化（匹配StagingTableA）。有时可能TableA会被修剪/清空并留下 0 行。

显然，当TableA为空时，直行INSERT将完成这项工作，但程序已被编写为使用一种MERGE INTO方法来处理所有场景。

位于MERGE .. MATCH索引列上。

我的问题是不确定如何MERGE处理将开始为空MATCH的情况TableA，然后在MERGE执行期间大幅增长。索引列将MATCH使用 FTS，因为统计信息将显示该表有 0 行。

在MERGE交易过程中的某个时刻，这将变得低效。

该MERGE语句是否足够聪明，可以检测到这一点并更改执行计划，并开始使用索引而不是 FTS？

如果这是用旧方式完成的，CURSOR那么我们可能会在适当的点（比如在处理 50,000 次之后）引入 a以切换到最佳计划。UPDATEINSERTANALYZETableA

我找不到任何处理这个特定问题的文档。

在我们的 MySQL 性能审查期间，我们看到我们的代码中有一些全表扫描。我们创建了一个跨越不同表的视图，这些表是主-从记录。例如，销售和销售线。

在这个主明细记录上，我们需要添加分页。所以我们必须能够获取前 10 个销售（以及它们相应的销售线）。还要获取前 10 个销售线，其中 1 个单价高于 10 美元。

所以我们创建了一个视图，在这个场景中是 vw_sales，它连接了销售和销售线，我们能够满足这些要求。

创建表可以在这里查看

视图创建为here

我们添加了如下分页

解释命令的结果如下所示

但是我们看到，由于 MySql（物化视图）的限制，我们导致了一些全表扫描 - 表 sale_test。（参考。如何让 MySQL 使用 INDEX 进行视图查询？，MySQL 视图是否总是进行全表扫描？）

跨表创建覆盖索引似乎是不可能的，所以这个选项也是不可能的。

我们已经在视图中添加了 force 索引以提示正确的索引，但这并不能解决问题。

这是如何以下降的方式解决的？创建一个临时表不会造成很多开销吗？这看起来很简单，但是分页要求使它变得非常困难。我们正在使用 mysql 5.7 (AWS RDS)，因此在 mysql 8.0 中添加的窗口函数对我们来说不是一个选项。

仅供参考：如果没有视图，我们会看到正在使用索引

询问：

结果

使用 postgres 9.6.11，我有一个类似的模式：

所有者：

动物：

在一些示例数据中：

所有者表：

动物表：

我需要执行的一个常见查询是通过宠物名称查找主人，我认为可以通过以下查询来完成：

但是我从这里得到的计划我不明白：

我不明白为什么查询计划进行顺序扫描。 我认为优化器会足够聪明，可以animal使用索引扫描表一次，甚至两次name，并根据此结果连接回所有者表，但结果却是一个非常意外的查询计划。

我采用了一个更简单的情况，我们只想查找狗的名字，并且查询的行为与我预期的一样：

此查询使用以下索引生成我理解的计划animal.name：

即使使用两个内部连接进行查询也会产生我期望的查询计划：

所以看起来左连接animal导致优化器忽略索引。

为什么做额外的左连接animal似乎会导致优化器忽略索引？

编辑：解释（分析，缓冲区）产生：

在带有查询优化器热修复的 SQL Server 2017（RTM-CU17）上，我有一个索引视图需要花费大量时间来更新。我不知所措，无法弄清楚为什么要进行全表扫描以进行更新。

索引视图有一个总和，并将主键上的两个表连接到具有高选择性的外键（每个主键平均 5 个外行）。如果更新了主表行，则通常会在外键表中查找聚合数据。如果该行有一个超出直方图范围的键（高于 RANGE_HI_KEY 的最大值），它决定使用外键对辅助表进行表扫描，即使辅助表在统计信息中有键值也是如此。我在生产中得到的估计有 1.1 亿行，但实际只有 6 行……相距甚远。由于它是升序键中的热数据，因此它实际上在找到所需的 6 行之前读取了所有 1.1 亿行。

我发现一个已修补的 Microsoft 问题与正在发生的事情非常相似，但在这种情况下没有纠正它：https: //support.microsoft.com/en-us/help/3192154/a-non-optimal-query -plan-choice-causes-poor-performance-when-values

由于我无法共享生产代码，我可以简单地重新创建它，并且可以在此处找到计划，一个带有边界搜索，一个带有越界扫描： https ://www.brentozar.com/pastetheplan/?id =SknQqFzy8

这是我用来创建上述计划的 SQL……非常简单。我不确定为什么会发生扫描，非常感谢任何帮助！

在尝试从多个连接表中提取大量列（~15-20）时，我将两个视图放在一起，它们可以提取必要的信息。但是，在我的本地数据库中（只有约 1kposts行），加入这些视图效果很好；当我在我们的生产数据库（约 30k 行）上创建相同的视图posts并尝试加入该视图时，我意识到该解决方案不会扩展到测试数据集之外。

我试图将这 2 个视图（类别数据——比如——categories.title和创作者的数据——比如.users.display_namepost_data

我已经将一个示例DBFiddle与一些测试数据放在一起来解释表结构。实际数据有更多列，但这代表了构建查询所需的连接。

在下面的查询中，符合条件的职位是在 base 中确定的SELECT；然后，将 post_data CTE 加入结果集（限制为 25 行）并返回 CTE 中的所有列。

理论上，我认为这可以通过根据基本选择标准选择行，然后根据 Post ID 对 CTE 进行索引扫描来实现；但是，查询优化器似乎选择对表进行全表扫描posts。

给EXPLAIN SELECT了我这个信息：

除此之外，我尝试重构查询以尝试强制在posts表中使用键，例如FORCE INDEX(PRIMARY)在选择中使用，并将 CTE 移动为基本查询并添加过滤器WHERE id IN ({the original base query})，但优化器似乎仍在进行全表扫描。

如果有助于解码查询计划中发生的事情：

• 在撰写本文时，有33,387 posts行，但查询计划显示
• 查询计划显示返回33,870行的全表扫描
• 查询计划还将派生表 ( <derived2>) 显示为具有493,911行

我的核心问题是：

1. 当我说子查询应该只对来自基本选择查询的每个结果行执行一次时，我是否正确？如果是这样，那么 CTE 也应该使用 JOINposts.id并可能使用表索引？

2. 为什么查询计划显示它只有33,387行时选择了 33,870 行？493,911 行是从哪里来的？

3. 在这种情况下如何防止全表扫描？