问题标签 [sql-tuning]

查询在一个巨大的表上运行（10 亿条记录 +）

从 TableA 中选择 Col1，其中 identcol >（从 ParamTable 中选择 bigint(identval)）

( identvaldataype is character and identcolis BIGINT) 这需要很长时间并且会进行全表扫描。当我替换子查询并在 identcol 的 where 子句中使用数字值时，它开始使用该列上的索引。

有没有办法强制 DB2 使用这个索引，而不指定文字值？（AIX 上的 DB2 9.7 luw）

编辑：我发现 BETWEEN 与子查询和上限值一起使用，并且还使用索引。此外，如果我删除显式转换为 BIGINT 它开始使用索引。但仍然想知道技术解释/指针。谢谢！

鉴于我们在关系数据库中有一个大表，我们需要查询。

我们有两个选择：

• 查询整个表
• 查询表内的数据子集，即从 1 到 1000 的行，然后是 1001 到 2000 等的行。

这种分离有意义吗？

它取决于查询结构吗？

让我们添加一些数学。给定一些查询执行时间与 n^3 成正比，其中 n 是表中的行数。这意味着在第一种情况下查询执行时间与 n^3 成正比。至于第二个选项 - 它不同。总时间为 (n/3)^3 + (n/3)^3 + (n/3)^3 = n^3 / 9 更好。

现实生活更复杂：在这种情况下查询不会相同，我们必须花一些时间将行限制为子集。

此外，数据库的连接数和并发性可能会受到限制，因此我们将无法同时通过 10 个查询来查询它，例如，至少以相同的速度。

但这些理由有意义吗？这可能有助于减少一些大桌子的时间费用吗？

我正在尝试从 sql server 上的 varchar2(8000) 文本字段插入数据。我在 oracle db 上创建了一个类似的列，但属于 clob 数据类型。你能帮我解决不一致的数据类型问题并提高查询的性能吗？请让我知道是否有任何其他更好的方法可以为多行插入巨大的文本文件。当我在 sql server 和 oracle db 上运行相同的查询（即从 TBL_NOTES@PPRLEG 中选择“Note”）时，可以快速检索结果。当我尝试插入数据时，它需要很长时间并且不会结束。我应该只在此处给出包含 clob 的列，它应该处理其余的。

/

是否有一条 SQL 语句可以让我列出 Teradata SQL 查询中涉及的所有对象（表视图 SP 的宏） - 很像 show select * from 而不扩展其 DDL 这将与 Visual Explain 相同做过。

我有一个像这样的查询

问题是 TB3 和 TB4 是巨大的事实表。事实表的 PI 不包含在此处的连接或查询中。

到目前为止我做了什么

是创建一个 volatile 表（与 IN LIST 相同的 pi）并尝试实现。VT1 具有与 TB4 相同的 PI，并将在 where 子句中包含 IN LIST。我喜欢这个使用方法

我如何优化这些类型的查询假设 tb3 和 tb2 是巨大的事实表。PI TB3 是 C4，c6 和 tb2 的 PI 是 C6，C7 TB3 有一个分区列 Cp，但不用于任何类型的 where 子句。它用于其中一个连接，他们没有相同的 PI，但可能在他们的 PI 中有一个共同的列 TB3 的行数约为 8000 万行，6000 万行。原始查询根本不会在没有假脱机的情况下运行。幸运的是，它可以在晚上使用 80K Impact C。只有在创建具有与 tb2 相同的 PI 的 VT2 然后使用它加入之后，我才能让查询在 < 200 Impact 中运行。我不想创建一堆 VT 供了解 TD 深蹲的 BO 用户使用。我能做些什么来让这个 Q 变得更好

我的理解是，大多数 OR 条件都可以在 UNION ALL 的性能优势处被替换。但是对于这 2 个查询，Count ('1') 是不一样的。为什么会这样-我在这里遗漏了什么。应该不一样吧。有人能解释一下差距吗

SQL #1

SQL #2

行数不一样。什么样的OR逻辑可以转换为等价的UNION ALL。

前几天我的查询有问题。一个大型数据集大约需要 10 秒。查询看起来像这样：

这运行得很慢。但是，然后我将其更改为：

这花了大约 0.01 秒，尽管这两个查询基本上产生了相同的结果！我查找了官方的 MySQL 文档，并在这里发现了一个有趣的评论：

在 OR 情况下使用索引会失去速度优势 (4.1.10)：

SELECT * FROM a WHERE index1 = 'foo' UNION SELECT * FROM a WHERE index2 = 'baar';

比

SELECT * FROM a WHERE index1 = 'foo' OR index2 = 'bar';

所以，我的问题有 3 个部分：

• 在生产系统（即数据集非常大的地方）的选择查询中使用 OR 子句真的很糟糕吗？
• 这个 OR 查询可以通过索引以某种方式调整吗？现在，我用于过滤的查询中的两列实际上都已编入索引。我可以创建一些棘手的复合索引以使 OR 像 UNION ALL 一样快吗？
• 这是特定于供应商的问题，还是我在使用 Oracle 或 Postgresql 时会遇到同样的问题？

我有一个简单的查询：

该查询通常执行 0.5s：

但是具有未注释条件的相同查询执行了 5s (!!!) 并且有一个非常奇怪的执行计划 (Revisions 和 SqlServers 虽然没有链接列并且最具选择性的条件 "r2l.[ChecksumWasSent] = 0 AND r2l .Status = 2" 在查询处理结束时执行：

ValidationStatus 是普通的 int 非空列。列 Revision2UploadLocations.RevisionId、Revisions.DatabaseId、Databases.InstanceId 已编入索引。以下是表的说明：

如何提高此查询的性能？

编辑现在我有更多详细信息：一些表（SqlServers 和数据库）有 1-10 条记录，但 Revisions 和 Revision2UploadLocations）有 500K+ 记录，因此查询优化决定使用全扫描而不是索引搜索小表并首先使用它。 查询性能调优（SQL Server Compact）：

小表格是其内容适合一个或几个数据页的表格。避免索引非常小的表，因为执行表扫描通常更有效。

作为临时解决方案，我尝试使用查询提示FORCE ORDER：查询提示（SQL Server Compact） 和响应时间从 5 秒减少到 0.5 秒。

但我认为这不是一个好的解决方案。

I am using a statement as below and get this error:

SELECT Failed. 3771: Illegal expression in WHEN clause of CASE expression.

I had better hopes from Teradata. SQL Server can do it but Teradata can't. How can I work around this? Any solution?

我对这些情况有很多疑问

有没有更好的方法来重写过滤条件

选择了一些 cols 一些不是在 sel Vs 过滤条件中存在的。