Questions tagged «query-performance»

有关改善数据库查询的性能和/或效率的问题。

1
如何优化查询
我有一个与此类似的数据库结构， CREATE TABLE [dbo].[Dispatch]( [DispatchId] [int] NOT NULL, [ContractId] [int] NOT NULL, [DispatchDescription] [nvarchar](50) NOT NULL, CONSTRAINT [PK_Dispatch] PRIMARY KEY CLUSTERED ( [DispatchId] ASC, [ContractId] ASC )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY] ) ON [PRIMARY] GO CREATE TABLE …
1
OPTION FORCE ORDER提高性能，直到删除行
我有一个稍微复杂的SQL Server 2008查询（大约200行相当密集的SQL），但没有按照我的需要执行。随着时间的流逝，性能从大约0.5秒下降到大约2秒。 看一下执行计划，很明显，通过重新排序联接，可以提高性能。我做到了，而且做到了……下降到约0.3秒。现在，该查询具有“ OPTION FORCE ORDER”提示，并且生活很顺利。 今天，我来了，清理数据库。我存档了大约20％的行，除了删除行外，在相关数据库中不执行任何操作...执行计划的执行总数为软管。它会完全判断某些子树将返回多少行，并且（例如）替换为： <Hash> 与 <NestedLoops Optimized='false' WithUnorderedPrefetch='true'> 现在，查询时间从大约0.3秒增加到大约18秒。（！）只是因为我删除了行。如果删除查询提示，我将返回大约2秒的查询时间。更好，但是更糟。 将数据库还原到多个位置和服务器后，我重现了该问题。简单地从每个表中删除大约20％的行总是会导致此问题。 对于强制联接顺序来说，使查询估计完全不准确（从而使查询时间无法预测）是否正常？ 我应该只是希望我要么必须接受次优的查询性能，要么像鹰一样看着它并经常手动编辑查询提示？还是暗示每个联接？.3s至2s是一个很大的选择。 很明显，为什么优化器在删除行后就炸毁了？例如，“是的，它进行了一次样本扫描，并且由于我在数据历史记录中较早地归档了大多数行，因此样本产生了稀疏的结果，因此它低估了对排序后的哈希操作的需要”？ 如果您想查看执行计划，请建议一个可以张贴它们的位置。否则，我将采样最惊人的部分。这是基本的错误估计，paren中的数字是（估计：实际）行。 / Clustered Index Scan (908:7229) Nested Loops (Inner Join) --< \ NonClustered Index Seek (1:7229) 请注意，内部循环应扫描908行，但扫描52,258,441。如果准确，则此分支将运行约2毫秒，而不是12秒。在删除行之前，此内部联接估计值的总和仅为2，并且对两个聚簇索引进行哈希匹配。
2
慢的性能将几行插入到巨大的表
我们有一个流程，该流程从商店获取数据并更新公司范围的库存表。该表按日期和项目列出了每个商店的行。对于拥有许多商店的客户，此表可能会非常大-大约5亿行。 随着商店输入数据，此库存更新过程通常一天运行多次。这些运行仅更新来自少数商店的数据。但是，客户也可以运行此程序以更新例如过去30天中的所有商店。在这种情况下，该过程启动了10个线程，并在一个单独的线程中更新了每个商店的库存。 客户抱怨该过程需要很长时间。我已经概要分析了该过程，发现一个将INSERTs插入此表的查询所消耗的时间比我预期的要多得多。该插入有时会在30秒内完成。 当我对此表运行临时SQL INSERT命令（由BEGIN TRAN和ROLLBACK绑定）时，临时SQL完成的时间大约为毫秒。 执行缓慢的查询如下。这个想法是插入不存在的记录，然后在我们计算各种数据位时更新它们。该过程的上一步已确定了需要更新的项目，进行了一些计算，并将结果填充到tempdb表Update_Item_Work中。此过程在10个单独的线程中运行，并且每个线程在Update_Item_Work中都有其自己的GUID。 INSERT INTO Inventory ( Inv_Site_Key, Inv_Item_Key, Inv_Date, Inv_BusEnt_ID, Inv_End_WtAvg_Cost ) SELECT DISTINCT UpdItemWrk_Site_Key, UpdItemWrk_Item_Key, UpdItemWrk_Date, UpdItemWrk_BusEnt_ID, (CASE UpdItemWrk_Set_WtAvg_Cost WHEN 1 THEN UpdItemWrk_WtAvg_Cost ELSE 0 END) FROM tempdb..Update_Item_Work (NOLOCK) WHERE UpdItemWrk_GUID = @GUID AND NOT EXISTS -- Only insert for site/item/date combinations that don't …
1
如何获得准确的查询性能？
我正在尝试提高存储过程的性能。当我运行SP时，它几乎立即完成，就好像已缓存了某些内容一样。有人告诉我在SSMS中执行SP之前，请使用以下两行SQL： DBCC DROPCLEANBUFFERS DBCC FREEPROCCACHE 当我使用上面两行代码运行SP时，大约需要8秒钟。但是，这是否真的给了我真正的执行时间（就像我从应用程序中运行一样）？我怎么知道？
2
非常相似的查询，性能差异很大
我有两个非常相似的查询 第一个查询： SELECT count(*) FROM Audits a JOIN AuditRelatedIds ari ON a.Id = ari.AuditId WHERE ari.RelatedId = '1DD87CF1-286B-409A-8C60-3FFEC394FDB1' and a.TargetTypeId IN (1,2,3,4,5,6,7,8,9, 11,12,13,14,15,16,17,18,19, 21,22,23,24,25,26,27,28,29,30, 31,32,33,34,35,36,37,38,39, 41,42,43,44,45,46,47,48,49, 51,52,53,54,55,56,57,58,59, 61,62,63,64,65,66,67,68,69, 71,72,73,74,75,76,77,78,79) 结果：267479 计划：https：//www.brentozar.com/pastetheplan/？id = BJWTtILyS 第二个查询： SELECT count(*) FROM Audits a JOIN AuditRelatedIds ari ON a.Id = ari.AuditId WHERE ari.RelatedId = '1DD87CF1-286B-409A-8C60-3FFEC394FDB1' …
1
使用pg_trgm索引进行相似性搜索的查询时间慢
我们在表中添加了两个pg_trgm索引，以启用按电子邮件地址或名称的模糊搜索，因为我们需要按名称或注册过程中拼写错误的电子邮件地址（例如“ @ gmail.con”）查找用户。ANALYZE在创建索引后运行。 但是，在绝大多数情况下，对这两个索引中的任何一个进行排名搜索都非常缓慢。也就是说，随着超时的增加，查询可能会在60秒内返回，在极少数情况下可能会很快返回15秒，但通常查询会超时。 pg_trgm.similarity_threshold是的默认值0.3，但将其提高0.8似乎没有什么不同。 这个特定的表有超过2500万行，并且不断地对其进行查询，更新和插入（每个表的平均时间小于2ms）。设置为PostgreSQL 9.6.6，在具有通用SSD存储和或多或少默认参数的RDS db.m4.large实例上运行。pg_trgm扩展是1.3版。 查询： SELECT * FROM users WHERE email % 'chris@example.com' ORDER BY email <-> 'chris@example.com' LIMIT 10; SELECT * FROM users WHERE (first_name || ' ' || last_name) % 'chris orr' ORDER BY (first_name || ' ' || last_name) <-> 'chris orr' LIMIT …
2
是什么导致此查询/执行计划的CPU使用率过高？
我有一个支持.NET Core API应用程序的Azure SQL数据库。浏览Azure门户中的性能概述报告表明，我的数据库服务器上的大部分负载（DTU使用情况）来自CPU，特别是一个查询： 如我们所见，查询3780几乎负责服务器上的所有CPU使用率。 这有点说得通，因为查询3780（见下文）基本上是应用程序的整个关键所在，并且用户经常调用它。这也是一个相当复杂的查询，需要许多联接才能获得所需的正确数据集。该查询来自一个存储库，最终看起来像这样： -- @UserId UNIQUEIDENTIFIER SELECT C.[Id], C.[UserId], C.[OrganizationId], C.[Type], C.[Data], C.[Attachments], C.[CreationDate], C.[RevisionDate], CASE WHEN @UserId IS NULL OR C.[Favorites] IS NULL OR JSON_VALUE(C.[Favorites], CONCAT('$."', @UserId, '"')) IS NULL THEN 0 ELSE 1 END [Favorite], CASE WHEN @UserId IS NULL OR C.[Folders] IS NULL THEN …
1
SQL Server查询存储是否捕获参数值？
SQL Server 2016中引入的新查询存储很棒。它是我以前使用较旧的Profiler工具所做的大部分工作的理想替代品。但是，我还没有找到一种方法来捕获与嗅探到的高资源消耗查询的各个调用相关的参数值。这可能吗？ 我知道查询存储处理的是聚合数据而不是单个调用，因此我怀疑我在这里可能不走运。当我发现一个慢查询时，我发现它很方便进行故障排除，使其参数也与其最慢的调用之一相关联。我想知道如何使用最新最好的工具来执行此操作。（我不会错过使用Profiler！） 从安全角度来看，查询存储的锁定程度是否低于Profiler？我认为它需要从某个级别的单个调用中捕获数据才能计算聚合。只是不确定是否存储了其中的任何一个。
1
通过删除运算符哈希匹配内部联接来提高查询性能
在尝试将以下问题的内容应用于我自己的情况时，我有点困惑，因为如果可能的话，如何摆脱运算符哈希匹配（内部联接）。 SQL Server查询性能-无需哈希匹配（内部联接） 我注意到了10％的成本，并且想知道是否可以降低它。请参阅下面的查询计划。 这项工作来自我今天必须调整的一个查询： SELECT c.AccountCode, MIN(d.CustomerSID) FROM Stage.Customer c INNER JOIN Dimensions.Customer d ON c.Email = d.Email OR ( c.HomePostCode = d.HomePostCode AND c.StrSurname = d.strSurname ) GROUP BY c.AccountCode 在添加这些索引之后： --------------------------------------------------------------------- -- Create the indexes --------------------------------------------------------------------- CREATE NONCLUSTERED INDEX IDX_Stage_Customer_HOME_SURNAME_INCL ON Stage.Customer(HomePostCode ,strSurname) INCLUDE (AccountCode) --WHERE HASEMAIL …
1
PostgreSQL中的SQL每小时​​数据聚合
我是数据库的新手，因此正在寻求您的帮助。 我有一个包含时间序列数据的表。 2012/01/01 00:10, 10 2012/01/01 00:30, 5 2012/01/01 01:00, 10 2012/01/01 01:40, 10 2012/01/01 02:00, 20 该表通过仅保留间隔的上限来存储基于间隔的数据。例如，第一行代表从[00:00-00:10]到10的间隔，第二行代表从（00:10-00:30]到5的间隔，第三行代表（00:30-01:00）的时间间隔，值为10。 我需要在Postgres中进行高效的查询，以汇总每小时数据，以获取上述结构。因此结果将是这样的： 2012/01/01 00:00, 2012/01/01 01:00, 25 2012/01/01 01:00, 2012/01/01 02:00, 30 请注意，时间序列数据很大，因此对其建立索引的任何帮助将不胜感激。 谢谢，丹
2
为什么不使用我的计划指南？
最近，我们遇到了临界点问题，由于查询优化器会忽略搜索列上的非聚集索引，因此一些过去几秒钟即可完成执行的报表查询现在要花费2分钟以上的时间。下面的示例查询： select top 100 * from [dbo].[t_Call] where ID > 0 and throwtime between '3/20/2014 7:00:00 AM' and '3/24/2014 6:59:59 AM' order by id 该ID列是聚集索引，并且Throwtime具有非聚集索引。在这种情况下，我们注意到使用了排序方式throwtime而不是ID更改查询计划和非聚集索引。我们还计划归档一些旧数据（当前有2000万行！！）。但是在应用程序中进行这些更改将需要一些时间，我需要找到一种方法使报表运行得相当快，而无需在应用程序级别进行更改（哦，这就是生命！）。 输入计划指南。我使用非聚集索引查询提示创建了以下计划指南，由于某种原因，仍然不使用非聚集索引。我想念什么吗？ EXEC sp_create_plan_guide @name = N'[prod2reports_callthrowtime]', @stmt = N'select top 100 * from [dbo] . [t_Call] where ID > @0 and @1 < = ThrowTime …
1
太多的空闲连接会影响PostgreSQL 9.2的性能吗？
我的数据库服务器上的某些查询似乎需要很长时间才能响应，而且我认为CPU使用率很高。运行时ps aux，我看到约250个“空闲”连接（我认为数量太多）。我还没有开始做完整的诊断，但是我想知道这是否是一个开始寻找的好地方。 我还在事务级池中使用PgBouncer。我怀疑可以idle通过调整池大小来轻松减少连接数。但是，除非有充分的理由，否则我不想开始进行太多更改。 idlePostgreSQL 9.2中的许多连接会影响性能吗？ 非常感谢！
3
在只读副本上长时间运行的查询会占用主数据库上的时间
我有一个4节点AG设置，如下所示： 所有节点的VM硬件配置： Microsoft SQL Server 2017企业版（RTM-CU14）（KB4484710） 16个vCPU 356 GB RAM（长话短说...） 最大并行度：1（根据应用程序供应商的要求） 并行成本阈值：50 服务器最大内存（MB）：338944（331 GB） AG配置： 节点1：主节点或同步提交不可读的辅助节点，配置为自动故障转移 节点2：主节点或同步提交不可读的辅助节点，配置为自动故障转移 节点3：具有异步提交的可读辅助集，配置为手动故障转移 节点4：具有异步提交的可读辅助节点集，配置为手动故障转移 有疑问的查询： 此查询没有什么疯狂的，它提供了应用程序内各种队列中未完成工作项的摘要。您可以从下面的执行计划链接之一查看代码。 主节点上的执行行为： 在主要节点上执行时，执行时间通常约为1秒标记。这是执行计划，以下是从主节点从STATISTICS IO和STATISTICS TIME捕获的统计信息： (347 rows affected) Table 'Worktable'. Scan count 647, logical reads 2491, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, …
3
如何更快地获得最近行的总数？
我目前正在设计交易表。我意识到将需要计算每一行的运行总计，这可能会降低性能。因此，出于测试目的，我创建了一个包含一百万行的表。 CREATE TABLE [dbo].[Table_1]( [seq] [int] IDENTITY(1,1) NOT NULL, [value] [bigint] NOT NULL, CONSTRAINT [PK_Table_1] PRIMARY KEY CLUSTERED ( [seq] ASC )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY] ) ON [PRIMARY] GO 我尝试获取10个最近的行及其运行总计，但大约花了10秒钟。 --1st attempt SELECT TOP 10 seq …
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.