Questions tagged «query-performance»

问这个问题，特别是对Postgres，因为它对R树/空间索引有很好的支持。 下表具有单词及其频率的树结构（嵌套集模型）： lexikon ------- _id integer PRIMARY KEY word text frequency integer lset integer UNIQUE KEY rset integer UNIQUE KEY 和查询： SELECT word FROM lexikon WHERE lset BETWEEN @Low AND @High ORDER BY frequency DESC LIMIT @N 我认为覆盖索引(lset, frequency, word)会很有用，但如果范围内的lset值过多，我可能会认为效果不佳(@High, @Low)。 (frequency DESC)当使用该索引的搜索提早产生@N与范围条件匹配的行时，使用简单的索引有时也足够了。 但是，性能似乎在很大程度上取决于参数值。 有没有一种方法可以使它快速执行，而不管该范围(@Low, @High)是宽还是窄，以及无论哪个高频字都幸运地处于选定的（狭窄）范围内？ R树/空间索引会有所帮助吗？ 添加索引，重写查询，重新设计表，没有任何限制。

29 postgresql  database-design  index  query-performance 

我们有一个数据仓库，它的记录数很大（10-20百万行），并且经常运行查询来对某些日期之间的记录进行计数，或者对带有某些标志的记录进行计数，例如 SELECT f.IsFoo, COUNT(*) AS WidgetCount FROM Widgets AS w JOIN Flags AS f ON f.FlagId = w.FlagId WHERE w.Date >= @startDate GROUP BY f.IsFoo 性能并不是很糟糕，但可能会相对缓慢（在冷缓存中可能为10秒）。 最近，我发现我可以GROUP BY在索引视图中使用，因此尝试了类似于以下内容的操作 CREATE VIEW TestView WITH SCHEMABINDING AS SELECT Date, FlagId, COUNT_BIG(*) AS WidgetCount FROM Widgets GROUP BY Date, FlagId; GO CREATE UNIQUE CLUSTERED …

28 sql-server  index  query-performance  materialized-view 

我正在执行更新，其中我需要对tstzrange变量进行完全相等的处理。约100万行被修改，查询耗时约13分钟。的结果EXPLAIN ANALYZE可以在此处看到，实际结果与查询计划者估算的结果有很大不同。问题在于索引扫描开启t_range期望返回一行。 这似乎与以下事实有关：范围类型的统计信息与其他类型的统计信息存储方式不同。综观pg_stats为列图，n_distinct是-1和其它字段（例如most_common_vals，most_common_freqs）是空的。 但是，必须在t_range某处存储统计信息。一个非常相似的更新，其中我在t_range上使用“内”而不是完全相等，需要大约4分钟的时间来执行，并且使用完全不同的查询计划（请参阅此处）。第二个查询计划对我来说很有意义，因为将使用临时表中的每一行以及历史记录表的大部分。更重要的是，查询计划人员为上的过滤器预测了大约正确的行数t_range。 的分布t_range有点不寻常。我正在使用此表存储另一个表的历史状态，并且对另一个表的更改会在大型转储中一次全部发生，因此没有许多不同的值t_range。以下是与的每个唯一值相对应的计数t_range： t_range | count -------------------------------------------------------------------+--------- ["2014-06-12 20:58:21.447478+00","2014-06-27 07:00:00+00") | 994676 ["2014-06-12 20:58:21.447478+00","2014-08-01 01:22:14.621887+00") | 36791 ["2014-06-27 07:00:00+00","2014-08-01 07:00:01+00") | 1000403 ["2014-06-27 07:00:00+00",infinity) | 36791 ["2014-08-01 07:00:01+00",infinity) | 999753 t_range以上不同的计数已经完成，因此基数约为3M（其中1M会受到任一更新查询的影响）。 为什么查询1的性能比查询2差得多？就我而言，查询2是一个很好的替代品，但是如果确实需要精确的范围相等性，我如何才能使Postgres使用更智能的查询计划？ 带索引的表定义（删除不相关的列）： Column | Type | Modifiers ---------------------+-----------+------------------------------------------------------------------------------ history_id | integer | not null default nextval('gtfs_stop_times_history_history_id_seq'::regclass) t_range …

28 postgresql  query-performance  postgresql-9.3  postgresql-performance  range-types 

如果在视图内部或外部过滤视图，这会有所不同吗？ 例如，这两个查询之间有什么区别吗？ SELECT Id FROM MyTable WHERE SomeColumn = 1 要么 SELECT Id FROM MyView WHERE SomeColumn = 1 并且MyView定义为 SELECT Id, SomeColumn FROM MyTable 如果源表位于链接服务器上，答案是否有所不同？ 我之所以问是因为我必须从链接的服务器查询一个大表（4400万行）两次，并获得结果的汇总。我想知道是否应该创建两个视图来访问数据，每个查询一个视图，还是我可以放弃一个视图和一个WHERE子句。

28 sql-server  sql-server-2005  view  query-performance 

我有一个数据库，在其中我将文件加载到临时表中，从该临时表中我有1-2个连接来解析一些外键，然后将这些行插入到最终表中（每月有一个分区）。我有大约34亿行用于三个月的数据。 使这些行暂存到最终表中的最快方法是什么？SSIS数据流任务（使用视图作为源并激活快速加载）或插入INTO SELECT ....命令？我尝试了“数据流任务”，并在5个小时内可以得到大约10亿行（8核/服务器上192 GB RAM），这对我来说感觉很慢。

27 sql-server  sql-server-2012  query-performance  insert 

我知道存储过程通过执行路径（比应用程序中的内联sql）更有效。但是，当按下时，我对原因并不了解。 我想知道这一点的技术原因（以便以后可以向某人解释）。 谁能帮我制定一个好的答案？

27 sql-server  stored-procedures  query-performance 

考虑SQL Server 2014中的以下查询计划： 在查询计划中，自联接ar.fId = ar.fId产生的估计值为1行。但是，这在逻辑上是不一致的估计：ar只有20,608行，并且只有一个不同的值fId（准确地反映在统计数据中）。因此，此联接产生行（~424MMrow）的全叉积，导致查询运行几个小时。 我很难理解为什么SQL Server会提出一个很容易证明与统计数据不一致的估计。有任何想法吗？ 初步调查和其他细节 根据Paul 在这里的答案，似乎用于估计联接基数的SQL 2012和SQL 2014启发式方法应该可以轻松处理需要比较两个相同直方图的情况。 我从跟踪标志2363的输出开始，但无法轻松理解。下面的代码段是否表示SQL Server正在比较的直方图fId和bId以便估计仅使用的联接的选择性fId？如果是这样，那显然是不正确的。还是我误读了跟踪标志输出？ Plan for computation: CSelCalcExpressionComparedToExpression( QCOL: [ar].fId x_cmpEq QCOL: [ar].fId ) Loaded histogram for column QCOL: [ar].bId from stats with id 3 Loaded histogram for column QCOL: [ar].fId from stats with id 1 Selectivity: 0 请注意，我想出了几种变通办法，这些变通办法包含在完整的repro脚本中，并将此查询缩短为毫秒。这个问题的重点是了解行为，如何在以后的查询中避免它，以及确定它是否应与Microsoft一起提交。 …

27 sql-server  query-performance  sql-server-2014  execution-plan  cardinality-estimates 

我正在使用PostgreSQL（9.4）数据库在Ruby on Rails中开发应用程序。在我的用例中，表中的列将被非常频繁地查找，因为应用程序的重点是在模型上搜索非常特定的属性。 我目前正在决定是使用一种integer类型还是只使用典型的字符串类型（例如character varying(255)，Rails中的默认字符串类型）作为列，因为我不确定索引的性能会有什么不同。 这些列是枚举。对于具有的可能值的数量，它们具有固定的大小。大多数枚举长度不超过5，这意味着该索引在应用程序的整个生命周期中或多或少是固定的；因此，整数和字符串索引的节点数将相同。 但是，将被索引的字符串可能长约20个字符，这在内存中大约是整数的5倍（如果整数是4个字节，并且字符串是每个字符1个字节的纯ASCII，则成立）。我不知道数据库引擎怎么做索引查找窗口，但如果它需要“扫描”的字符，直到它匹配准确，那么在本质上这意味着该字符串查找就超过5倍的整数查找速度较慢; 直到匹配整数查找为止的“扫描”将是4个字节而不是20个字节。这就是我的想象： 查找值为（整数）4： 正在扫描.........................找到| 正在获取记录... | BYTE_1 | BYTE_2 | BYTE_3 | BYTE_4 | BYTE_5 | BYTE_6 | BYTE_7 | BYTE_8 | ... | 查找值是（字符串）“ some_val”（8个字节）： 扫描................................................. ....................................发现| 正在获取记录... | BYTE_1 | BYTE_2 | BYTE_3 | BYTE_4 | BYTE_5 | BYTE_6 | BYTE_7 | …

26 postgresql  index  query-performance  index-tuning  postgresql-performance 

对于我来说，我有一个关于可保存性的有趣问题。在这种情况下，它是关于两个日期列之间的差异使用谓词。设置如下： USE [tempdb] SET NOCOUNT ON IF OBJECT_ID('tempdb..#sargme') IS NOT NULL BEGIN DROP TABLE #sargme END SELECT TOP 1000 IDENTITY (BIGINT, 1,1) AS ID, CAST(DATEADD(DAY, [m].[severity] * -1, GETDATE()) AS DATE) AS [DateCol1], CAST(DATEADD(DAY, [m].[severity], GETDATE()) AS DATE) AS [DateCol2] INTO #sargme FROM sys.[messages] AS [m] ALTER TABLE [#sargme] ADD …

24 sql-server  index  query-performance 

我已经在Itzik Ben-Gan的 PCMag中阅读了这些文章： 搜寻并您应扫描第一部分：当优化程序未优化 搜寻时，您应扫描第二部分：升序键 我目前所有分区表都遇到“最大分组”问题。我们使用Itzik Ben-Gan提供的技巧来获取max（ID），但有时它无法运行： DECLARE @MaxIDPartitionTable BIGINT SELECT @MaxIDPartitionTable = ISNULL(MAX(IDPartitionedTable), 0) FROM ( SELECT * FROM ( SELECT partition_number PartitionNumber FROM sys.partitions WHERE object_id = OBJECT_ID('fct.MyTable') AND index_id = 1 ) T1 CROSS APPLY ( SELECT ISNULL(MAX(UpdatedID), 0) AS IDPartitionedTable FROM fct.MyTable s WHERE $PARTITION.PF_MyTable(s.PCTimeStamp) = …

22 sql-server  query-performance  partitioning 

这个问题与我的旧问题有关。以下查询需要10到15秒才能执行： SELECT [customer].[Customer name],[customer].[Sl_No],[customer].[Id] FROM [company].dbo.[customer] WHERE (Charindex('123456789',CAST([company].dbo.[customer].[Phone no] AS VARCHAR(MAX)))>0) 在一些文章中，我看到使用索引CAST并CHARINDEX不会从中受益。也有一些文章说使用LIKE '%abc%'将不会从索引中受益，而LIKE 'abc%'将会： http://bytes.com/topic/sql-server/answers/81467-using-charindex-vs-like-where /programming/803783/sql-server-index-any-improvement-for -like-queries http://www.sqlservercentral.com/Forums/Topic186262-8-1.aspx#bm186568 就我而言，我可以将查询重写为： SELECT [customer].[Customer name],[customer].[Sl_No],[customer].[Id] FROM [company].dbo.[customer] WHERE [company].dbo.[customer].[Phone no] LIKE '%123456789%' 此查询提供与上一个相同的输出。我为column创建了一个非聚集索引Phone no。当我执行此查询时，它将在1秒内运行。与之前的14秒相比，这是一个巨大的变化。 如何LIKE '%123456789%'从索引中受益？ 为什么列出的文章指出它不会提高性能？ 我尝试重写要使用的查询CHARINDEX，但是性能仍然很慢。为什么CHARINDEX在LIKE查询中没有从索引中受益呢？ 使用查询CHARINDEX： SELECT [customer].[Customer name],[customer].[Sl_No],[customer].[Id] FROM [Company].dbo.[customer] WHERE ( Charindex('9000413237',[Company].dbo.[customer].[Phone no])>0 ) 执行计划： 使用查询LIKE： SELECT [customer].[Customer …

22 sql-server-2008-r2  index  query-performance 

我需要一个可以在（或作为）函数中使用的查询，并检索n值的所有组合。我需要长度为k的所有组合，其中k = 1..n。 扩展的样本输入和结果，因此输入具有3个值而不是2个-但是，输入值的数量可能从1到n不等。 示例：输入：具有多行一列中的值的表 Value (nvarchar(500)) ------ Ann John Mark 输出＃1：表，其值串联在一栏中 Ann John Mark Ann,John John,Mark Ann,Mark Ann,John,Mark

22 sql-server  query-performance 

说，我们有这样的查询： select a.*,b.* from a join b on a.col1=b.col1 and len(a.col1)=10 假设以上查询使用哈希联接并具有残差，则探测键为col1，残差为len(a.col1)=10。 但是，通过另一个示例，我可以看到探针和残差在同一列。以下是我要说的话的详细说明： 查询： select * from T1 join T2 on T1.a = T2.a 执行计划，突出显示探针和残差： 测试数据： create table T1 (a int, b int, x char(200)) create table T2 (a int, b int, x char(200)) set nocount on declare @i int …

21 sql-server  query-performance  execution-plan  database-internals 

我有一个存储过程，该过程通过覆盖索引从索引视图返回结果。通常，它运行速度很快（〜10毫秒），有时甚至可以运行8秒钟。 这是一个随机执行的示例（注意：这不是一个缓慢的执行，但是查询文本与传递的值相同）： declare @p2 dbo.IdentityType insert into @p2 values(5710955) insert into @p2 values(5710896) insert into @p2 values(5710678) insert into @p2 values(5710871) insert into @p2 values(5711103) insert into @p2 values(6215197) insert into @p2 values(5710780) exec ListingSearch_ByLocationAndStatus @statusType=1,@locationIds=@p2 这是SPROC： ALTER PROCEDURE [dbo].[ListingSearch_ByLocationAndStatus] @LocationIds IdentityType READONLY, @StatusType TINYINT AS BEGIN SET NOCOUNT ON; …

20 sql-server  sql-server-2012  query-performance  azure-vm 

在下面的查询计划摘要中，很明显，该Concatenation运算符的行估计应为~4.3 billion rows，或其两个输入的行估计之和。 但是，~238 million rows会产生一个估计值，从而导致次优Sort/ Stream Aggregate策略，该策略会将数百GB的数据溢出到tempdb。在这种情况下，逻辑上一致的估计将产生Hash Aggregate，消除了溢出，并显着提高了查询性能。 这是SQL Server 2014中的错误吗？在任何合理的情况下，估算值低于输入值可能是合理的？可能有哪些解决方法？ 这是完整的查询计划（匿名）。我没有对该服务器的sysadmin访问权限，无法提供来自QUERYTRACEON 2363或类似跟踪标记的输出，但是如果有帮助的话，也许可以从管理员那里获取这些输出。 该数据库的兼容性级别为120，因此正在使用新的SQL Server 2014基数估计器。 每次加载数据时都会手动更新统计信息。给定数据量，我们当前正在使用默认采样率。较高的采样率（或FULLSCAN）可能会产生影响。

20 sql-server  query-performance  sql-server-2014  concat  cardinality-estimates