标签: performance

在生产应用程序（C# 与 SQL Server 2014 Standard 对话）中，有一个如下所示的查询。大多数情况下，它以毫秒为单位运行。但偶尔（对于 的某些值@Id），它会发疯并需要一分钟左右的时间。这比应用超时时间长，因此用户的应用失败。

在“疯了”的情况下，返回的结果集是正确的，因为它在许多但不是所有其他情况下都是空的。

幸运的是，这在生产和开发环境中都是可重现的。

开发人员说从查询中删除“TOP 1”，然后确保应用程序使用结果集的额外行，清除性能问题。

查询规划器在TOP 1存在时建议没有索引。（在开发中）。

正在更改查询并修复应用程序。推出需要一段时间。

我的问题：是否有任何 DBA 可访问的方法来调整或调整生产 SQL Server 实例以在新查询推出应用程序更改之前解决此问题？

SELECT TOP 1
       subscription_id 
  FROM subscription AS sub
  JOIN billing_info AS bi ON bi.billing_info_id = sub.billing_info_id   
  JOIN person_group AS apg ON apg.person_id = bi.person_id
  JOIN pplan ON pplan.plan_id = sub.plan_id
  JOIN product ON product.product_id = [plan].product_id 
  JOIN product_attribute ON product_attribute.product_id = product.product_id 
 WHERE apg.group_id = @Id
   AND apg.start_date < GETDATE()
   AND (apg.end_date IS NULL …

以下对外部的查询在 320 万行上执行大约需要 5 秒：

SELECT x."IncidentTypeCode", COUNT(x."IncidentTypeCode") 
FROM "IntterraNearRealTimeUnitReflexes300sForeign" x 
WHERE x."IncidentDateTime" >= '05/01/2016' 
GROUP BY x."IncidentTypeCode" 
ORDER BY 1;

当我在普通表上执行相同的查询时，它会在 0.6 秒内返回。执行计划完全不同：

普通表

SELECT x."IncidentTypeCode", COUNT(x."IncidentTypeCode") 
FROM "IntterraNearRealTimeUnitReflexes300sForeign" x 
WHERE x."IncidentDateTime" >= '05/01/2016' 
GROUP BY x."IncidentTypeCode" 
ORDER BY 1;

外表

Sort  (cost=226861.20..226861.21 rows=4 width=4) (actual time=646.447..646.448 rows=7 loops=1) 
  Sort Key: "IncidentTypeCode" 
  Sort Method: quicksort  Memory: 25kB 
  -> HashAggregate (cost=226861.12..226861.16 rows=4 width=4) (actual  time=646.433..646.434 rows=7 loops=1)
     Group Key: "IncidentTypeCode"
     -> Bitmap Heap Scan on "IntterraNearRealTimeUnitReflexes300s" x  (cost=10597.63..223318.41 rows=708542 width=4) …

作为一个简化的例子，假设我有一个这样的表：

seq | value
----+------
102 | 11954
211 | 43292
278 | 19222
499 |  3843

该表可能包含数亿条记录，我需要经常做这样的查询：

SELECT sum(value) WHERE seq > $a and seq < $b

即使seq被索引，典型的数据库实现也会遍历每一行以计算最佳情况下的总和O(n)，其中n是范围的大小。

是否有任何数据库可以像O(log(n))每个查询一样有效地执行此操作？

我所遇到的数据结构称为段树所描述这里。有时也称为范围树或区间树，尽管所有这些名称通常被描述为数据结构的略微不同的变体。

但是，我还没有遇到任何实现这种数据结构的数据库。对于内存结构来说，从头开始实现它很容易，但如果它必须持久化或太大而无法放入内存，则变得棘手。如果有一种在现有数据库之上实现这一点的有效模式，那也会有所帮助。

旁注：这不是仅附加表，因此在这种情况下，诸如保留累积总和之类的解决方案将不起作用。

我有一个查询，其中使用select *不仅读取少得多，而且使用的 CPU 时间也比使用select c.Foo.

这是查询：

select top 1000 c.ID
from ATable a
    join BTable b on b.OrderKey = a.OrderKey and b.ClientId = a.ClientId
    join CTable c on c.OrderId = b.OrderId and c.ShipKey = a.ShipKey
where (a.NextAnalysisDate is null or a.NextAnalysisDate < @dateCutOff)
    and b.IsVoided = 0
    and c.ComplianceStatus in (3, 5)
    and c.ShipmentStatus in (1, 5, 6)
order by a.LastAnalyzedDate

这以 2,473,658 次逻辑读取结束，大部分在表 B 中。它使用了 26,562 个 CPU，持续时间为 7,965。

这是生成的查询计划：

关于 PasteThePlan：https ://www.brentozar.com/pastetheplan/ ? …

我在4个vCPU VM运行Microsoft SQL Server 2016 SP2-CU6（13.0.5292.0）与max degree of parallelism设置为2和cost threshold for parallelism设置为50。

早上，当我尝试显示SELECT TOP 100查询的估计执行计划时，我遇到了大量等待，并且呈现估计计划的操作需要几分钟，通常在 5 到 7 分钟的范围内。同样，这不是查询的实际执行，这只是显示Estimated Execution Plan 的过程。

sp_WhoIsActive将显示PAGEIOLATCH_SH等待或LATCH_EX [ACCESS_METHODS_DATASET_PARENT]等待，当我在操作期间运行Paul Randal 的 WaitingTasks.sql脚本时，它显示CXPACKET等待，工作线程显示PAGEIOLATCH_SH等待：

*资源描述字段= exchangeEvent id=Port5f6069e600 WaitType=e_waitPortOpen waiterType=Coordinator nodeId=1 tid=0 ownerActivity=notYetOpened waiterActivity=waitForAllOwnersToOpen

工作线程看起来将整个stats表带入内存（因为这些页码以及从 Paul Randal 的查询点显示的后续页码指向stats表的聚集键）。一旦计划确实回来了，即使在我看到stats缓存中的大部分表损耗，只剩下各种记录（我认为由于类似查询的搜索操作而被拉出）之后，它在当天剩余时间内基本上是即时的。

如果查询实际上是使用使用 SCAN 运算符的计划执行的，我会期望这种初始行为，但是为什么在评估执行计划时这样做只是为了到达上面链接的计划中所示的 SEEK 运算符？我可以做些什么（除了在办公时间之前运行此语句以便适当缓存我的数据）来帮助提高性能？我假设一对覆盖索引将是有益的，但它们真的能保证行为的任何变化吗？我必须在此处处理一些存储和维护窗口限制，并且查询本身是从供应商解决方案生成的，因此此时欢迎任何其他建议（除了更好的索引）。

在常规 Google App Engine 使用、polymodel 或普通“Bigtable”模型中，什么产生最佳性能？

多模型有效地在父表中创建了一个名为“类”的列，它提供了继承跟踪。而从父类继承的普通 Bigtable 创建了一个新的独立数据结构，无法查询父类并找到所有子类型类的所有子类。

我们有一个使用 Microsoft SQL 数据库的现成应用程序。在这个应用程序中，我们为每个报告挑选和选择各种选择标准。此应用程序然后运行这些报告。

我相信我们有一个查询计划问题。我们每天运行的第一个报表，运行速度非常快 7 分钟。我们在第一个报告之后运行的任何报告都需要一个多小时。

每天晚上，我们都会运行一个计划任务来停止和启动 SQL Server 代理和 SQL Server。在这个 SQL Server 实例中还有大约 25 个其他数据库。没有其他数据库有性能问题，只有我之前提到的现成产品。

有没有办法清除 SQL Server 当前内存中的所有查询计划？

如何在不影响依赖同一服务器上其他数据库的 30 个左右的用户的情况下执行此操作？

在同一台物理机上跨另一个数据库执行选择时是否会影响性能？所以我在同一个 SQL 2008 实例中运行的同一台物理机器上有 2 个数据库。

例如在 SomStoreProc on_this_db 我运行 SELECT someFields FROM the_other_db.dbo.someTable

到目前为止，我在互联网上读到的内容，大多数人似乎都表示不。

我正在使用PostgreSQL 8.3 + PostGIS 1.3在Ubuntu 8.04 Hardy上存储地理空间数据。

这个特定版本的 PostGIS 在计算buffer()非常复杂的段时有一个错误，这会导致查询占用越来越多的内存，直到整个机器卡住。

我正在寻找一种 PostgreSQL 机制，它可以：

• 限制特定查询使用的内存消耗（可能还有其他资源）。
• 自动停止执行时间超过某个阈值的查询。

有任何想法吗？

显然，保留几个不同的索引会对插入和删除性能产生负面影响。查询性能如何：在表上保留太多索引是否有意义？在任何情况下，如果添加索引（当然对于使用索引的查询），查询性能是否会提高，或者甚至有可能因索引过多而导致查询性能下降，因为有必要查阅所有索引以获得结果？

如果表上有不同的索引：它们会被全部考虑，还是仅从优化器的角度来看是最好的？Oracle 是否实现了多维索引？