问题标签 [query-tuning]

我很难在包含略多于 2 亿条记录的表上创建包含索引。表结构如下：

问题是当我执行以下查询时：

..然后在 ~27ms 内检索结果（有一个non-clustered indexon 列UserId）。

但是，当我尝试选择其他列时，例如：

..然后结果会在大约 2,000 毫秒内返回。

查看执行计划： ..显然，这Key Lookup是花费最多时间的地方。

我试图在 上创建一个包含索引VatId，例如：

..但是经过几个小时的运行，这个查询以错误告终

池中内存不足（默认）

（我的 SQL Server 实例在 8GB RAM、Core i7 上运行）

我的问题：有没有其他可能的技巧来摆脱这个Clustered Key Lookup并提高性能？

非常感谢

编辑： 该列Id有一个聚集索引。

调用set statistics io on;产生以下结果：

编辑 2： 只是为了制作完整的图片，带有提示的执行计划：

有一个像`

然后将列表推到 volatile 表中是最好的出路。然而，这是通过 cognos 完成的，IBM 不够聪明，无法知道 Teradata 的 volatile 表是什么。我希望这样我可以使用排除逻辑 Exists 来检查易失性表的内容。所以没有 volatile table ，我有一个值列表 where a.c1 in ( list ) ，它有 5K 个值。在报告中保留该列表被证明是昂贵的。我想知道是否可以在将此类列表放入报告之前将其存储在某个地方。CTE 和使用存在于 CTE 上怎么样，是否会获得类似的收益。

我在 Amazon RDS db.r3.4xlarge 实例上运行 Postgres 9.4.4 - 16CPU，122GB 内存。我最近遇到了一个查询，它需要在一张大表（约 2.7 亿条记录）上进行相当直接的聚合。该查询需要 5 多个小时才能执行。

大表上的连接列和分组列定义了索引。我已经尝试通过将work_mem和temp_buffers设置为1GB来进行试验，但它帮助很大。

这是查询和执行计划。任何线索将不胜感激。

这是执行计划 -

我正在 mysql 中编写一个查询来连接两个表。并且这两个表都有超过 50,000 条记录。

表 EMP 列 empid,

项目，

代码，

地位

表 EMPINFO

空虚，

项目，

代码，

项目类型，

所花费的时间，

技能

在每个表中都有候选键 [empid, project, code]

所以当我使用 INNER join 加入表时

我得到了结果，但是如果我在外部查询中添加 count(*) 来计算记录数，那么连接失败会花费很多时间。

有什么方法可以加快获取记录的数量吗？

我想听听更多关于加快内部连接查询以及在两个表中具有相同候选键的建议。

我有一个包含 EntityID 列的大约 200,000 条记录的列表，我将其加载到临时表变量中。

如果 Temp 表中的 EntityID 在 dbo.EntityRows 表中不存在，我想插入 Temp 表变量中的任何记录。dbo.EntityRows 表包含大约 800,000 条记录。

与 dbo.EntityRows 表有大约 500,000 条记录时相比，该过程非常缓慢。

我的第一个猜测是因为 NOT EXISTS 子句，Temp 变量中的每一行都必须扫描 dbo.EntityRows 表的整个 800k 行以确定它是否存在。

问题：是否有其他方法可以在不使用 NOT EXISTS 的情况下运行此比较检查，这会产生巨大的成本并且随着 dbo.EntityRows 继续增长只会变得更糟？

编辑：欣赏评论。这是查询（我在 IF NOT EXISTS 检查之后省略了部分。之后，如果 NOT EXISTS，我插入到 4 个表中）。

我已经打破了尝试创建索引或更改 mysql 配置以改进查询的想法，但我没有得到它。有人可以帮助我吗？

我正在创建一个拥有超过 400 万个产品的系统，为了提高用户的响应时间，我正在创建一个物化视图。

要创建此视图，我使用下面的查询

但是，随着时间的推移和产品的增加，创建此表需要大约 4 个小时。是否可以提高表或配置的移动性能指标？

脚本创建表

和

和

和

下面的查询需要 5+ 秒的时间来执行（表包含 1m+ 条记录）。外部查询没有使用正确的索引它总是通过使用全表扫描来获取数据。有人可以帮我如何优化它..

询问

查询说明

查询统计

执行计划

我有一个奇怪行为的查询，因为在某些情况下它需要 120 秒和另外 250 秒。我必须尽量减少执行时间，但找不到帮助我改善查询运行时间的指南。

包含信息的表格具有以下特征：

1. 所有字段都重复
2. 它有8亿条记录
3. 进程 14.2 GB

查询是这样的：

有一个指南或提示可以帮助我优化运行时，不仅是这个查询，还有未来的查询？

我正在研究 Sybase IQ 16 性能调整。寻求专家的帮助来调整我的查询。

1）是否有会生成计划输出的命令。2）是否有任何通用指南/步骤来调整查询。

我有一个 UNIX 脚本 在这个脚本中，我们使用 SQL Loader 创建表、索引并从文件加载日期到该表。并在此表上进行近 70 次直接更新（不用于全部或批量收集）。

最后，我们将这个新表数据插入到另一个表中。它每天处理 500 000 条记录。所有这些更新都非常快。

在将此数据插入另一个表期间需要 20 分钟。如何改进？

1. 插入没有问题，因为在同一张表上，我们正在从另一个工作正常的表中插入 500 000 个校长。插入不到一分钟。

插入表格（）从tablex中选择（）；500 000 条 Tablex 记录需要 20 分钟——在同一个 shell 脚本中创建、加载、70 条直接更新。

检查了单独选择和插入脚本的解释计划成本都相同。

插入表格（）从表格中选择（）；上述语句执行不到一秒钟。

• 我使用了并行提示。成本降低。而且cpu利用率为零。
• 我应该再创建一个表 tablez 然后将数据从 tablez 加载到我的最终表吗？
• 是否需要统计数据收集？这是每日运行程序。