Questions tagged «optimization»

在数据库的上下文中,优化是指查询优化器选择有效的物理执行计划的过程。

2
MySQL:delete…where..in()vs delete..from..join,并使用subselect锁定删除表
免责声明:请原谅我缺乏数据库内部知识。它去了: 我们运行的应用程序(不是我们编写的)在数据库的定期清理作业中存在很大的性能问题。查询如下所示: delete from VARIABLE_SUBSTITUTION where BUILDRESULTSUMMARY_ID in ( select BUILDRESULTSUMMARY_ID from BUILDRESULTSUMMARY where BUILDRESULTSUMMARY.BUILD_KEY = "BAM-1"); 直截了当,易于阅读和标准SQL。但不幸的是非常缓慢。对查询进行解释说明VARIABLE_SUBSTITUTION.BUILDRESULTSUMMARY_ID未使用现有索引on : mysql> explain delete from VARIABLE_SUBSTITUTION where BUILDRESULTSUMMARY_ID in ( -> select BUILDRESULTSUMMARY_ID from BUILDRESULTSUMMARY -> where BUILDRESULTSUMMARY.BUILD_KEY = "BAM-1"); | id | select_type | table | type | possible_keys | key …

2
多行插入与多个单行插入
在我的应用程序中,我会尽可能执行多行插入操作,因为这会减少数据库与应用程序之间的往返次数。 但是,我很好奇,还有其他优势吗?例如,如果像这样一次插入多行: insert into tbl (c1, c2) values (v1, v2) (v3, v4) 与: insert into tbl (c1, c2) values (v1, v2) insert into tbl (c1, c2) values (v3, v4) 并且该表具有索引,在第一种情况下该索引是计算一次,在第二种情况下是两次计算?还是每次插入总是一次?假定两个查询都在同一事务中。 我正在使用PostgreSQL。

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,并且对两个聚簇索引进行哈希匹配。


1
在MySQL DB Server中运行OPTIMIZE TABLE查询的好处
我想知道OPTIMIZE TABLE tbl_name在MySQL Server中运行查询可以带来的[真正实用]好处。 我检查了一次,发现运行此命令后,下一个数据库命中可能花费很长时间,可能是由于碎片的重定位所致,但是随后的命中表现出某种性能,我不确定查询缓存是否能做到这一点与优化或仅优化一起完成此技巧。 如果可能的话,任何人都可以用一些实际的性能差异值来指导我,以便随着MySQL的使用在我们的项目中日益受到重视,我可以继续做下去。

3
Yelp如何有效地计算数据库中的距离?
例如,说我有一张桌子: Business(BusinessID, Lattitude, Longitude) 所有这些都被索引了。也有一百万条记录 假设我想寻找最接近106.5的企业,该怎么办? 如果我做 SELECT * FROM Business WHERE (Some formula to compute distance here) < 2000 例如,或者如果我这样做 SELECT * FROM Business TOP 20 理论上,计算机将必须计算所有biz的距离,而实际上,只有那些纬度和经度在一定范围内的距离才应计算。 那么,如何在PhP或SQL中做我想做的事情? 到目前为止,我很感谢您的回答。我正在使用mysql,它们没有比明显的解决方案更有效的方法。MySQL空间也没有计算距离功能。

4
如何进一步优化此MySQL查询?
我的查询要花特别长的时间(15+秒),并且随着时间的推移,随着数据集的增长,查询只会变得越来越糟。我过去对此进行了优化,并添加了索引,代码级排序和其他优化,但是还需要进一步完善。 SELECT sounds.*, avg(ratings.rating) AS avg_rating, count(ratings.rating) AS votes FROM `sounds` INNER JOIN ratings ON sounds.id = ratings.rateable_id WHERE (ratings.rateable_type = 'Sound' AND sounds.blacklisted = false AND sounds.ready_for_deployment = true AND sounds.deployed = true AND sounds.type = "Sound" AND sounds.created_at > "2011-03-26 21:25:49") GROUP BY ratings.rateable_id 查询的目的是让我获得sound id以及最近发布的声音的平均评分。大约有1500种声音和200万种评级。 我有几个指数 sounds …


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
“警告:操作导致残留的I / O”与关键查找
我在SQL Server 2017执行计划中看到了以下警告: 警告:操作导致剩余IO [sic]。实际读取的行数为(3,321,318),但返回的行数为40。 这是SQLSentry PlanExplorer的片段: 为了改进代码,我添加了非聚集索引,因此SQL Server可以访问相关行。它工作正常,但通常索引中将包含太多(大)列。看起来像这样: 如果我仅添加索引,而没有包含列,则强制使用索引,如下所示: 显然,SQL Server认为密钥查找比剩余的I / O昂贵得多。我有一个没有大量测试数据的测试设置(但是),但是当代码投入生产时,它需要处理更多的数据,所以我很确定需要某种非聚集索引。 当您在SSD上运行时,关键查询真的那么昂贵吗?我必须创建全脂索引(包含很多包含列)吗? 执行计划: https : //www.brentozar.com/pastetheplan/?id=SJtiRte2X这是一个长存储过程的一部分。寻找IX_BatchNo_DeviceNo_CreatedUTC。

2
重建-聚集索引,表或两者?
我在任何地方都找不到确切的资源,因此希望一位专家可以在这里给我答案。 我有一个很大的表,我们必须在其中添加一列。聚集索引非常分散,我想做一个ALTER INDEX REBUILD清理它。 我通常ALTER TABLE REBUILD在更改列时也会执行一次,因为这会清除该操作中的所有指针或拆分。 因为我们在谈论聚集索引,本质上就是表,我是否需要同时做这两个事情? 我怀疑ALTER INDEX REBUILD集群中的不会更新遗嘱的所有内容ALTER TABLE,但是我也担心ALTER TABLE不会清理索引碎片。

2
为什么带有参数的此递归CTE在处理文字时不使用索引?
我在树结构上使用递归CTE来列出树中特定节点的所有后代。如果我在WHERE子句中写入文字节点值,则SQL Server似乎实际上仅将CTE应用于该值,从而给出了具有较少实际行数的查询计划,等等: 但是,如果我将值作为参数传递,它似乎实现了(假脱机)CTE,然后在事实之后对其进行过滤: 我可能看错了计划。我还没有注意到性能问题,但是我担心CTE的实现会导致更大数据集的问题,尤其是在繁忙的系统中。另外,我通常会自己遍历此遍历:我遍历祖先,然后遍历到后代(以确保收集所有相关节点)。由于我的数据如何,每组“相关”节点都非常小,因此实现CTE没有任何意义。当SQL Server似乎意识到CTE时,它给我的“实际”数量带来了相当大的数目。 有没有办法让查询的参数化版本像文字版本一样工作?我想将CTE放在可重用的视图中。 用文字查询: CREATE PROCEDURE #c AS BEGIN; WITH descendants AS (SELECT t.ParentId Id ,t.Id DescendantId FROM #tree t WHERE t.ParentId IS NOT NULL UNION ALL SELECT d.Id ,t.Id DescendantId FROM descendants d JOIN #tree t ON d.DescendantId = t.ParentId) SELECT d.* FROM descendants d WHERE …


4
在查询中的多个列上调用同一个表值函数的最有效方法
我正在尝试优化一个查询,其中在20列上调用了相同的表值函数(TVF)。 我所做的第一件事是将标量函数转换为内联表值函数。 是否使用CROSS APPLY最佳执行方式对查询中的多个列执行相同的功能? 一个简单的例子: SELECT Col1 = A.val ,Col2 = B.val ,Col3 = C.val --do the same for other 17 columns ,Col21 ,Col22 ,Col23 FROM t CROSS APPLY dbo.function1(Col1) A CROSS APPLY dbo.function1(Col2) B CROSS APPLY dbo.function1(Col3) C --do the same for other 17 columns 有更好的选择吗? 可以在针对X个列的多个查询中调用同一函数。 功能如下: CREATE …

1
SQLite3不使用带有json_extract表达式的覆盖索引
我正在尝试SQLite3使用json_extract表达式在(3.18)中创建索引。我的目标是执行只需要索引即可产生结果的查询。这样做的原因是json_extract操作昂贵,在较大的数据集和/或值上进行操作时会降低性能。我得出结论,我需要一个覆盖指数来满足我的需求。 步骤1-使用标准表结构测试理论 CREATE TABLE Player ( Id INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL, FirstName TEXT NOT NULL, MiddleName TEXT, LastName TEXT NOT NULL ); CREATE INDEX Player_FirstName ON Player ( FirstName ASC, LastName ASC ); EXPLAIN QUERY PLAN SELECT FirstName, LastName FROM Player WHERE LENGTH(LastName) > 10 ORDER BY FirstName …

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.