问题标签 [sql-tuning]

我发现“count( ) over()”会比“select count( ) from table”快得多。

例如

使用 count( *) 结束

with CTE as( select col_A,col_B,totalNumber=count(*) over() from table1 where conditions..) select totalNumber from CTE

使用 select count( *) from ( 或者也使用 count(1) )

select count(*) from table1 where conditions..

在我对SQL Server 2K5的本地测试中，如果搜索条件复杂且返回的行很大，则count( ) over* 将快 4 倍。

但是为什么 count(**) over 执行得这么快呢？

谢谢你的建议。

万斯

更新

我认为真的错过了一些细节：

实际上，我使用“准备语句” sql 进行测试，例如：

exec sp_executesql N'SELECT count(*) FROM tableA WHERE (aaa in(@P0)) AND (bbb like @P1)', N'@P0 nvarchar(4000),@P1 nvarchar(4000)',N'XXXXXXX-XXXX-XXX',N'%AAA%'

Execution Plan says "HashMatch" cost 61%, others is "index seek". And the execution time will be 1484ms and logical reads around 4000.

与

SELECT count(*) FROM tableA WHERE (aaa in('XXXXXXX-XXXX-XXX')) AND (bbb like '%AAA%') Execution plan says "clustered index seek" cost 98%. And the execution time is 46ms and logical reads will be 8000.

如果将第一个 sql 更改为：

exec sp_executesql N'with CTE as( SELECT total=count(*) over () FROM tableA WHERE (aaa in(@P0)) AND (bbb like @P1)) select top 1total from cte', N'@P0 nvarchar(4000),@P1 nvarchar(4000)',N'XXXXXXX-XXXX-XXX',N'%AAA%' Execution plan says "clustered index seek 58%', no "hashmatch join" occurs.

And the execution time is 15ms and logical reads is: 8404.

那么，“哈希匹配连接”是否对性能有很大的开销？

以下查询旨在接收用户的未读消息列表。它涉及 3 个表：recipients包含用户与消息 ID 的关系，messages包含消息本身，以及message_readers包含哪些用户已阅读哪些消息的列表。

查询可靠地花费了 4.9 秒——这严重损害了我们的性能，尤其令人担忧，因为我们希望数据库最终会大几个数量级。诚然，它本质上是一个繁重的查询，但数据集很小，直觉上它似乎应该快得多。服务器有足够的内存（32gb），整个数据库应该一直加载到 RAM 中，并且盒子上没有其他东西在运行。

桌子都很小：

查询本身：

解释计划非常简单：

上有一个索引message_readers.read_by_id，但我想它不能真正使用它，因为 IS NULL 条件。

我正在使用所有默认设置，但以下设置除外：

谢谢！

你们能否请查看以下对 Oracle DB 的查询并指出问题所在：

查询统计：

• 耗时：10.53 秒。

指数：

• t2.empno被索引。

• t1.id被索引。

• t2.id被索引。

更新

上面的查询只是我使用的查询的一个示例副本。下面以更真实的形式

解释计划

询问：

索引列：

桌子

表 2

合并加入笛卡尔总是危险的吗？

我有许多查询，成本从 7 到 40 不等，但遵循合并连接笛卡尔执行。

当我的查询成本较低时，我真的应该为 Merge Join 笛卡尔而烦恼吗？

我真的需要这方面的帮助。

任何帮助是极大的赞赏。

谢谢，萨维莎

我有一个如下所示的查询，表 A、T、S 有大约 100 万行，而 P 有超过 1 亿行。我在这个查询中新引入了内联视图“temp”，它导致性能急剧下降。为 temp 检索到的数据几乎没有 50 行，而且这个内联查询在单独执行时会迅速运行。

自动跟踪统计显示“一致获取”的数量从 6 位数字显着增加，然后将 temp 添加到 9 位数字！此外，超过 90% 的 LAST_CR_BUFFER_GETS 用于“临时”视图。如果我将此视图中的数据提取到一个临时表中并将该表用作连接的一部分，则性能非常好，但该解决方案对我来说并不可行。

我知道这个问题非常笼统，但我想知道使用这个内联视图是否有什么小错误。内联视图不会提供与将这些数据放在临时表中相同的性能吗？有什么方法可以提示 Oracle 以有效的方式使用此视图，从而提高性能。

我正在开发 Oracle 10gR2

我有一个表 TBL_CUSTOMER 的 MERGE 语句。TBL_CUSTOMER 包含一列 USERNAME，其中包含电子邮件地址。此表中存储的数据不区分大小写，如传入数据可以是大写、小写或任意大小写组合。

在合并数据时，我必须确保在不考虑大小写的情况下比较数据。我已经创建了一个基于 USERNAME 列的函数索引作为 UPPER(USERNAME)。

当我检查解释计划时，没有使用基于 USERNAME 的函数索引。我注意到，如果我删除 OR 条件，则使用索引，但由于复杂的业务逻辑，我无法删除它。

如何强制使用该索引？

我在 MySQL 平台上运行以下 SQL 查询。

表 A 是具有单列（主键）和 25K 行的表。表 B 有几列和 75K 行。

执行以下查询需要 20 分钟。如果您能提供帮助，我将很高兴。

我有一个 OWB 映射，它从临时表中获取输入并将这些行添加到多维数据集。多维数据集背后的基础表是使用外键与维度连接的关系事实表。查询背后的解释计划成本相当高，映射运行时间为 30 分钟。如果您在下面看到，在第 17 步中，成本上升到 1,396,573，这也是嵌套循环开始出现的地方。有人可以提供一般指针来调整这个查询吗？

计划

我有两张表，一张包含 ID <-> 名称映射，另一张表包含多个 ID 列。要列出第二个表的记录以及相应的 ID 名称，我有一个类似的查询

这是唯一的方法吗？因为为每一行的每个 ID 列查询第二个表。

当我们在一个查询中连接超过 2-3 个表时，如果我们在所有表中都有一个公共列，那么我们在执行时会不会有什么不同？

1. 为所有表中的公共列指定值。

   例如：

   /li>

2. 为其中一个公用列赋予价值并与另一列连接

   例如：

   /li>

问这个问题的原因是，我有一个查询（成本为 17），它在我指定示例 1 中的值时执行，但如果我加入示例 2 中的列，它会挂起并且永远不会执行。

请帮助我理解这一点。