Questions tagged «optimization»

我一直在我们的MS SQL数据库上运行自动索引工具（我修改了源自Microsoft的脚本，该脚本查看索引统计表- 自动化自动索引）。现在，从统计信息中，我可以获得需要创建的索引的建议列表。 编辑： 上述索引从DMV那里获取信息，这些信息告诉您数据库引擎将使用哪些索引（如果索引可用），并且脚本采用Top x建议（按查找，用户影响等）并将它们放在表格中。 （上面的编辑部分摘自拉里·科尔曼（Larry Coleman）在下面的回答，以阐明脚本的作用。 由于我是数据库管理员的新手，并且已经在网上进行了快速搜索，因此我不愿意尝试并盲目添加推荐的索引。但是，由于没有该领域的经验，我正在寻找有关如何确定建议是否必要的建议。 我需要运行SQL事件探查器，还是最好检查查询表的代码？您还有其他建议吗？

110 sql-server  performance  index  optimization 

我在Ubuntu 12.04上使用PostgreSQL 9.1。 我需要选择一段时间内的记录：我的表time_limits有两个timestamp字段和一个integer属性。我的实际表中还有其他列不涉及此查询。 create table ( start_date_time timestamp, end_date_time timestamp, id_phi integer, primary key(start_date_time, end_date_time,id_phi); 该表包含大约2M条记录。 进行以下查询需要花费大量时间： select * from time_limits as t where t.id_phi=0 and t.start_date_time <= timestamp'2010-08-08 00:00:00' and t.end_date_time >= timestamp'2010-08-08 00:05:00'; 所以我尝试添加另一个索引-PK的倒数： create index idx_inversed on time_limits(id_phi, start_date_time, end_date_time); 我感觉性能有所提高：访问表中间的记录的时间似乎更合理：介于40到90秒之间。 但是对于时间范围的中间值，仍然需要数十秒的时间。定位到表格末尾时（按时间顺序），则要多两倍。 我explain analyze第一次尝试获取此查询计划： Bitmap Heap …

96 postgresql  index  optimization  postgresql-9.1  explain 

当通过多个联接创建表以用于分析时，何时使用视图而不是创建新表？ 我更喜欢使用视图的原因之一是数据库模式是由我们的管理员从Ruby内部开发的，而我对Ruby并不熟悉。我可以要求创建表，但是需要额外的步骤，在开发/测试新联接时，我希望有更大的灵活性。 我开始在SO的一个相关问题（何时使用R，何时使用SQL）的答案之后使用视图。投票最多的答案开始为“在SQL中进行数据操作，直到数据在单个表中，然后在R中进行其余操作。” 我已经开始使用视图，但是遇到了一些视图问题： 查询要慢得多 视图不会从生产中转储到我用于分析的备份数据库中。 视图是否适合此用途？如果是这样，我应该期望性能下降吗？有没有一种方法可以加快视图查询？

54 mysql  optimization  view 

以下是关于数据库设计的书的摘录（数据库设计ISBN：0-7645-7490-6）： 使用视图的危险是针对视图过滤查询，期望读取很大表的很小部分。应该在视图内完成所有筛选，因为在视图中的查询完成执行之后，将对视图本身进行任何筛选。视图通常对于加快开发过程很有用，但是从长远来看，它可能会完全破坏数据库性能。 以下是PostgreSQL 9.5文档的摘录： 充分利用视图是良好的SQL数据库设计的关键方面。通过视图，您可以在一致的接口后面封装表结构的详细信息，该表结构的详细信息可能会随着应用程序的发展而变化。 这两个来源似乎相互矛盾（“不使用视图设计”与“不使用视图设计”）。 但是，在PG视图中是使用规则系统实现的。因此，可能（这是我的问题），针对视图的任何筛选都将重写为视图中的筛选器，从而导致针对基础表的单个查询执行。 我的解释正确吗，PG将WHERE子句组合进了视图？还是单独运行它们？有没有简短，自成体系，正确（可编译）的示例？

45 postgresql  optimization  view 

我有一个类似以下的查询： DELETE FROM tblFEStatsBrowsers WHERE BrowserID NOT IN ( SELECT DISTINCT BrowserID FROM tblFEStatsPaperHits WITH (NOLOCK) WHERE BrowserID IS NOT NULL ) tblFEStatsBrowsers有553行。 tblFEStatsPaperHits已获得47.974.301行。 tblFEStatsBrowsers： CREATE TABLE [dbo].[tblFEStatsBrowsers]( [BrowserID] [smallint] IDENTITY(1,1) NOT NULL, [Browser] [varchar](50) NOT NULL, [Name] [varchar](40) NOT NULL, [Version] [varchar](10) NOT NULL, CONSTRAINT [PK_tblFEStatsBrowsers] PRIMARY KEY CLUSTERED …

40 sql-server-2008-r2  query  optimization 

对于我要优化的中等复杂查询，我注意到删除该TOP n子句会更改执行计划。我可能已经猜到，当查询中包含TOP n数据库引擎时，该查询将忽略该TOP子句而运行，然后最后仅将结果集缩减为所请求的n行。图形化的执行计划似乎表明是这种情况，这是TOP“最后一步”。但似乎还有更多的事情正在进行。 我的问题是，TOP n子句如何（以及为什么）影响查询的执行计划？ 这是我的情况的简化版本： 该查询匹配两个表A和B中的行。 如果没有该TOP子句，优化器估计表A将有19k行，表B将有46k行。对于A，返回的实际行数是16k，对于B，返回的行数是13k。散列匹配用于将两个结果集连接到a总共69行（然后应用排序）。这个查询很快发生。 当我添加TOP 1001优化器时，不使用哈希匹配；相反，它首先对表A的结果进行排序（相同的估计值/实际值为19k / 16k），并针对表B进行嵌套循环。表B的估计行数现在为1，奇怪的是，TOP n直接影响表B 针对B的估计执行次数（索引查找）-始终为2n + 1，在我的情况下为2003。如果我更改，则此估计值也会相应更改TOP n。当然，由于这是嵌套联接，因此实际执行次数为16k（表A中的行数），这会使查询速度变慢。 实际情况要复杂一些，但这捕获了基本思想/行为。使用索引查找来搜索两个表。这是SQL Server 2008 R2企业版。

35 sql-server  query-performance  execution-plan  optimization 

引起我注意的是，查询子句中的USING构造（而不是ON）在某些情况下可能会引入优化障碍。FROMSELECT 我的意思是这个关键词： 选择 * 从一个 加入b 使用（a_id） 仅在更复杂的情况下。 背景：此评论到这个问题。 我用这个了很多，从来没有发现过这么远。我对一个展示效果或进一步信息的链接的测试案例非常感兴趣。我的搜索工作空虚。 USING (a_id)与替代连接子句相比，完美的答案是显示性能较差的测试用例ON a.a_id = b.a_id- 如果这确实可能发生。

35 postgresql  performance  optimization  join  select 

让我们检查以下两个语句： IF (CONDITION 1) OR (CONDITION 2) ... IF (CONDITION 3) AND (CONDITION 4) ... 如果CONDITION 1是TRUE，将CONDITION 2被检查吗？ 如果CONDITION 3是FALSE，将CONDITION 4被检查吗？ 关于以下条件WHERE：SQL Server引擎会优化WHERE子句中的所有条件吗？程序员是否应该以正确的顺序放置条件，以确保SQL Server优化程序以正确的方式解决该问题？ 添加： 感谢Jack的链接，这让T-SQL代码感到惊讶： IF 1/0 = 1 OR 1 = 1 SELECT 'True' AS result ELSE SELECT 'False' AS result IF 1/0 = 1 AND 1 = …

33 sql-server  sql-server-2008  t-sql  optimization  condition 

该查询获取您关注的人创建的帖子列表。您可以追踪的人数不受限制，但是大多数人追踪的人数<1000。 使用这种查询方式，明显的优化将是缓存"Post"id，但是不幸的是我现在没有时间。 EXPLAIN ANALYZE SELECT "Post"."id", "Post"."actionId", "Post"."commentCount", ... FROM "Posts" AS "Post" INNER JOIN "Users" AS "user" ON "Post"."userId" = "user"."id" LEFT OUTER JOIN "ActivityLogs" AS "activityLog" ON "Post"."activityLogId" = "activityLog"."id" LEFT OUTER JOIN "WeightLogs" AS "weightLog" ON "Post"."weightLogId" = "weightLog"."id" LEFT OUTER JOIN "Workouts" AS "workout" ON "Post"."workoutId" …

30 postgresql  index  optimization  postgresql-performance 

在下面的查询中，两个执行计划都估计将对唯一索引执行1,000次查找。 搜索是由对同一源表的有序扫描驱动的，因此看起来应该最终以相同的顺序搜索相同的值。 两个嵌套循环都有 <NestedLoops Optimized="false" WithOrderedPrefetch="true"> 有人知道为什么第一个计划的成本为0.172434，而第二个计划的成本为3.01702吗？ （问题的原因是，由于明显降低了计划成本，因此向我建议了第一个查询，这是一种优化。实际上，我认为它似乎在做更多的工作，但我只是想解释这个差异。） ） 设定 CREATE TABLE dbo.Target(KeyCol int PRIMARY KEY, OtherCol char(32) NOT NULL); CREATE TABLE dbo.Staging(KeyCol int PRIMARY KEY, OtherCol char(32) NOT NULL); INSERT INTO dbo.Target SELECT TOP (1000000) ROW_NUMBER() OVER (ORDER BY @@SPID), LEFT(NEWID(),32) FROM master..spt_values v1, master..spt_values v2; INSERT INTO dbo.Staging …

27 sql-server  sql-server-2014  optimization 

我遇到了一些SELECT DISTINCT TOP N查询，这些查询似乎没有被SQL Server查询优化器优化。让我们从一个简单的例子开始：一个带有两个交替值的百万行表。我将使用GetNums函数生成数据： DROP TABLE IF EXISTS X_2_DISTINCT_VALUES; CREATE TABLE X_2_DISTINCT_VALUES (PK INT IDENTITY (1, 1), VAL INT NOT NULL); INSERT INTO X_2_DISTINCT_VALUES WITH (TABLOCK) (VAL) SELECT N % 2 FROM dbo.GetNums(1000000); UPDATE STATISTICS X_2_DISTINCT_VALUES WITH FULLSCAN; 对于以下查询： SELECT DISTINCT TOP 2 VAL FROM X_2_DISTINCT_VALUES OPTION (MAXDOP 1); …

27 sql-server  optimization  sql-server-2016 

我们在SQL Server中遇到了一个有趣的问题。考虑以下repro示例： CREATE TABLE #test (s_guid uniqueidentifier PRIMARY KEY); INSERT INTO #test (s_guid) VALUES ('7E28EFF8-A80A-45E4-BFE0-C13989D69618'); SELECT s_guid FROM #test WHERE s_guid = '7E28EFF8-A80A-45E4-BFE0-C13989D69618' AND s_guid <> NEWID(); DROP TABLE #test; 小提琴 请暂时忘记这种s_guid <> NEWID()情况似乎毫无用处-这只是一个最小的复制示例。由于NEWID()匹配某个给定常数的可能性非常小，因此每次都应将其评估为TRUE。 但事实并非如此。运行此查询通常返回1行，但有时（非常频繁，在10中超过1次）返回0行。我已经在系统上使用SQL Server 2008对其进行了复制，您可以使用上面链接的小提琴（SQL Server 2014）在线对其进行复制。 查看执行计划可以发现查询分析器显然将条件分为s_guid < NEWID() OR s_guid > NEWID()： ...这完全解释了为什么有时会失败（如果第一个生成的ID小于给定ID，而第二个ID大于给定ID）。 即使其中一个表达式不是确定性的，也允许SQL Server将其评估A <> …

26 sql-server  optimization 

我给人的印象是，LIKE在对未知场景进行所有优化时都使用运算符时，旧的和​​新的CE都使用9％的估计值（假设相关统计数据可用并且查询优化器不必求助于选择性猜测）。 当对信用数据库执行以下查询时，在不同的CE下我得到了不同的估计。在新的CE下，我收到了900行的估计值，而在旧的CE下，我收到了241.416的估计值，我不知道如何得出此估计值。有人能说清楚吗？ -- New CE (Estimate = 900) DECLARE @LastName VARCHAR(15) = 'BA%' SELECT * FROM [Credit].[dbo].[member] WHERE [lastname] LIKE @LastName; -- Forcing Legacy CE (Estimate = 241.416) DECLARE @LastName VARCHAR(15) = 'BA%' SELECT * FROM [Credit].[dbo].[member] WHERE [lastname] LIKE @LastName OPTION ( QUERYTRACEON 9481, QUERYTRACEON 9292, QUERYTRACEON 9204, QUERYTRACEON …

24 sql-server  sql-server-2014  optimization  statistics  cardinality-estimates 

我问这个问题是为了更好地了解优化器的行为并了解索引假脱机的限制。假设我将1到10000之间的整数放入堆中： CREATE TABLE X_10000 (ID INT NOT NULL); truncate table X_10000; INSERT INTO X_10000 WITH (TABLOCK) SELECT TOP 10000 ROW_NUMBER() OVER (ORDER BY (SELECT NULL)) FROM master..spt_values t1 CROSS JOIN master..spt_values t2; 并强制嵌套循环加入MAXDOP 1： SELECT * FROM X_10000 a INNER JOIN X_10000 b ON a.ID = b.ID OPTION (LOOP JOIN, …

23 sql-server  optimization  sql-server-2016  index-spool 

我看到对WITH查询（公用表表达式或CTE）的频繁引用充当了优化隔离，不允许服务器将过滤器下推到CTE查询中，将常用表达式从CTE中拉出，等等。成为SQL标准要求的行为。 CTE 绝对是PostgreSQL中的优化栅栏……但这是标准要求的，还是实际上只是实现细节？ 例如，这些邮件列表张贴声明或表明它是标准的： http://www.digipedia.pl/usenet/thread/11566/101385/ 在评论中提到它之后，我被问到了它的指定位置-在查看了SQL：2008的唯一草稿后，我获得了访问它的机会，但运气并不好。 我尚未深入研究该标准，因此希望有人提出以下建议：标准实际上需要PostgreSQL中CTE的优化范围吗？如果是这样，它在哪里指定？还是Pg邮件列表上的语句有误？ 另请参阅待办事项列表上的线程CTE优化围栏？。

23 postgresql  optimization  sql-standard