Questions tagged «performance»

因此，我有此审核表（跟踪数据库中任何表上的操作）： CREATE TABLE `track_table` ( `id` int(16) unsigned NOT NULL, `userID` smallint(16) unsigned NOT NULL, `tableName` varchar(255) NOT NULL DEFAULT '', `tupleID` int(16) unsigned NOT NULL, `date_insert` datetime NOT NULL, `action` char(12) NOT NULL DEFAULT '', `className` varchar(255) NOT NULL, PRIMARY KEY (`id`), KEY `userID` (`userID`), KEY `tableID` (`tableName`,`tupleID`,`date_insert`), KEY …

9 mysql  performance  innodb  delete 

在BigTable的设计拒绝了许多标准的关系型模式的哲学的，明确非规范化宁愿到细微的小表的大主机。 问题所在的较大区域之一是对多对多联接的建模。 对这些联接建模的一种方法是违反第一范式，然后将所有有趣的数据放入db.ListProperty（）中。尽管这具有从查询中进行搜索的能力，但我尚未探索搜索列表与提取另一个表的性能含义。 由于连接是不可能的，这是可以通过RelationshipProperties链接表。因此，只要付出足够的努力，就可以创建标准相交表（具有引用两个父表的联合主键的表）。有没有人探索过各种实现的性能影响？ -编辑- 虽然文档中建议的“密钥列表”确实是实现此目的的一种方法，但我对该类和其他实现的性能和异常率感兴趣。创建公用密钥列表是否有用？重复付出的努力值得付出代价吗？有更好的方法吗？

9 performance  google-app-engine 

我有两个非常相似的查询 第一个查询： 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' …

9 sql-server  performance  query-performance  optimization  execution-plan 

Postgres函数用波动性分类VOLATILESTABLEIMMUTABLE声明，或。众所周知，该项目使用内置功能的这些标签非常严格。并且有充分的理由。一个突出的例子：表达式索引仅允许IMMUTABLE函数，并且它们必须是真正不变的，以避免错误的结果。 用户定义的函数仍然可以自由地声明，如所有者选择的那样。该手册建议： 为了获得最佳的优化结果，您应该使用对它们有效的最严格的波动性类别来标记您的函数。 ...并添加了错误的波动率标签可能会出错的大量问题列表。 尽管如此，在某些情况下伪造的不变性还是有意义的。通常，当您知道该函数在您的范围内实际上是不变的。例： PostgreSQL是否支持“不区分重音”的排序规则？ 除了对数据完整性的所有可能影响，对性能有什么影响？人们可能会认为声明一个函数IMMUTABLE只会对性能有所帮助。是这样吗？ 声明功能波动会IMMUTABLE 损害性能吗？ 让我们假设当前的Postgres 10缩小了范围，但是所有最新版本都很有趣。

9 postgresql  performance  functions 

性能调整时，更重要的是： CPU时间或经过时间？ 是否存在其中一种情况比另一种情况更重要的情况？ 例如：性能调整时，CPU时间将减少约38％，但经过时间增加约22％。这是一个进步吗？

9 sql-server  performance  performance-tuning 

我有一个具有近2300万条记录的MySQL数据库表。该表没有主键，因为没有唯一的键。它有2列，均已索引。下面是它的结构： 以下是一些数据： 现在，我运行了一个简单的查询： SELECT `indexVal` FROM `key_word` WHERE `hashed_word`='001' 不幸的是，这花费了超过5秒钟才能检索数据并将其显示给我。我的未来表将有1500亿条记录，因此这一次非常高。 我运行Explain命令以查看发生了什么。结果如下。 然后，我使用以下命令运行配置文件。 SET profiling=1; SELECT `indexVal` FROM `key_word` WHERE `hashed_word` = '001'; SHOW profile; 以下是分析的结果： 以下是有关我的表格的更多信息： 那么，为什么要花这么长时间？他们也被索引！将来，我必须运行很多LIKE命令，因此这会花费太多时间。出了什么问题？

9 mysql  performance  innodb  select 

我需要维护一个项目的统计表，该表由项目列表及其用途组成（想想一个类似网站的网站，您希望在其中计算综合浏览量）。每次实例化一个项目时，我都需要增加特定项目的使用率。 我的第一个实现是： statistics( id integer NOT NULL, name character varying(255) NOT NULL, usage integer NOT NULL DEFAULT 0, ); UPDATE statistics SET usage = usage + 1 WHERE name = '<name>'; 我关心的是性能和并发性。更新过程将由数十个（也许是80-120）设备实例化，并且每秒可能会发生几次，所以我的问题是： 1）这种方法会保留并发性吗？（即，如果有多个设备“同时”请求更新，是否将每个请求都计入？） 2）您能建议一种实现结果的最佳方法吗？我希望在编写更新时会负担很多，而阅读会更频繁。是否存在增加值的特定功能？我正在查看“序列”，但不确定是否正确。 提前非常感谢您的任何建议

9 postgresql  performance  concurrency 

有很多说法说数据库大小不会在很大程度上影响性能。只要表上的索引适合内存，数据库就应该保持性能。 但是现实是什么？如果数据库体系结构不是最好的，则索引将无法容纳在内存中，并且可能存在大量冗余数据，是否只需删除冗余数据即可获得显着收益？我估计可以删除数据库中60-80％的数据。 我相信，减小数据库大小并增加RAM以使索引可以容纳在内存中将显着提高性能，这将为重新构建系统提供几个月的喘息空间。 是否还有其他因素（例如IO，碎片，工作数据集等）会影响基于数据库大小的性能？

9 mysql  performance 

我有一个数据库，我在其中使用嵌入式TVF（表值函数）而不是视图。例如，我可能在TVF [fnCarBrands]内将两个称为[汽车模型]和[汽车制造商]的表连接在一起。 然后，其他TVF会调用这些TVF进行进一步的处理和报告。因此，我可以使用函数[fnCarBrands]并连接到表[购买年份]以形成函数[fnCarBrandHistory]。以此类推，用于多层TVF。 我可以使用视图获得相同的功能，因为我的内联TVF实际上只是表和其他TVF的连接。 用这种方式编写的嵌入式TVF的性能与视图相比如何？

9 sql-server-2005  performance  view  functions 

使用相同的服务帐户和代理帐户分别为在一家小型公司（例如35台服务器）中运行的所有SQL Server实例运行SQL Server和SQL Agent是否会对性能产生负面影响？最大的数据库为0.5 GB。任何建议都欢迎。谢谢。

8 sql-server  performance  service-accounts 

我的数据库服务器上的某些查询似乎需要很长时间才能响应，而且我认为CPU使用率很高。运行时ps aux，我看到约250个“空闲”连接（我认为数量太多）。我还没有开始做完整的诊断，但是我想知道这是否是一个开始寻找的好地方。 我还在事务级池中使用PgBouncer。我怀疑可以idle通过调整池大小来轻松减少连接数。但是，除非有充分的理由，否则我不想开始进行太多更改。 idlePostgreSQL 9.2中的许多连接会影响性能吗？ 非常感谢！

8 postgresql  database-design  performance  query-performance 

我有一个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, …

8 sql-server  performance  query-performance  availability-groups  sql-server-2017 

访问临时表中的历史记录时遇到一个奇怪的问题。通过AS OF子句访问时间表中较旧条目的查询所花的时间比对最近历史条目的查询所花的时间更长。 历史表是由SQL Server生成的（包括日期列上的聚簇索引并使用页面压缩），我向历史表中添加了5000万行，而我的查询检索了大约25,000行。 我试图确定问题的根本原因，但无法识别。到目前为止，我已经测试了： 创建一个具有聚集索引的5000万行的测试表，以查看速度下降是否仅是由于数量引起的。我能够在固定时间（〜400ms）内检索到25K行。 从历史表中删除页面压缩。这对检索时间没有影响，但是确实增加了表的大小。 我尝试使用ID列和日期列直接访问历史记录表的行。这是事情变得更有趣的地方。我可以在〜400ms处访问表中的旧行，其中与AS OF子句一样，它需要1200ms的时间。我尝试对日期列上的测试表进行过滤，并且与对ID列进行过滤相比，发现了类似的减速。这使我相信日期比较是某些放缓的原因。 我想更多地看这个，但是我也想确保我没有吠错树。首先，在访问临时表中的较旧历史数据时，是否还有其他人遇到过相同的行为（我们仅注意到速度下降超过1000万行）？其次，我可以使用哪些策略来进一步隔离性能问题的根本原因（我刚刚开始研究执行计划，但对我来说仍然有点神秘）？ 执行计划 这些是简单的检索查询：第一个访问较旧的行，第二个访问较新的行。 旧行〜1200ms执行时间 最近的行〜350ms执行时间 表格详情 这些是时间表中的列。历史记录表具有相同的列，但没有主键（根据历史记录表的要求）： 以下是历史记录表上的索引：

8 sql-server  performance  temporal-tables 

这是数据库内部的问题。我使用的是PostgreSQL 9.5，我想知道为什么在FROM子句中设置返回函数（SRF）（也称为表值函数（TVF））运行速度较慢，例如当我执行这些命令时， CREATE TABLE foo AS SELECT * FROM generate_series(1,1e7); SELECT 10000000 Time: 5573.574 ms 它总是比 CREATE TABLE foo AS SELECT generate_series(1,1e7); SELECT 10000000 Time: 4622.567 ms 这里是否可以制定一条通用规则，以便我们应该始终在FROM子句之外运行Set-Returning Functions ？

8 postgresql  performance  functions  database-internals  set-returning-functions 

抱歉，很长，但是我想给您尽可能多的信息，以便对分析有所帮助。 我知道有几个帖子有类似的问题，但是，我已经关注了网上发布的这些帖子和其他信息，但是问题仍然存在。 我在SQL Server中遇到严重的性能问题，这使用户发疯。这个问题持续了好几年，直到2016年底由另一个实体管理，从2017年开始由我管理。 在2017年中，我能够按照Microsoft SQL Server 2012性能仪表板报告中指示的索引提示解决问题。效果是立竿见影的，听起来像魔术。在过去的日子里，几乎总是100％的处理器变得超级宁静，并且用户的反馈声也很高。甚至我们的ERP技术人员也很高兴，因为通常需要20分钟才能获得某些清单，最后他可以在几秒钟内完成。 但是，随着时间的流逝，它开始慢慢恶化。我避免创建更多索引，因为担心过多的索引会降低性能。但是在某些时候，我不得不删除那些没用的东西，并创建Performance Dashboard向我建议的新东西。但没有影响。 在ERP中进行保存和咨询时，感觉到的缓慢本质上。 我有专用于SQL Server 2016 Enterprise（64位）的Windows Server 2012 R2，具有以下配置： 处理器：Intel Xeon CPU E5-2650 v3 @ 2.30GHz 记忆体：84 GB 在存储方面，服务器具有专门用于操作系统的卷，专门用于数据的卷和专门用于日志的卷。 17个数据库 使用者： 在最大的数据库中，大约有113个用户并发连接 另外约有9位使用者 其中两个是3 + 3 其余各只有1个用户 我们有一个网站，它也为较大的数据库编写数据，但是使用情况不那么常规，应该有大约20个用户。 数据库大小： 最大的数据库有290 GB 第二大有100GB 第三大有20 GB 第四个14 GB 其余各只有3 GB以上 这是生产实例，但我们也有一个开发实例，我相信可以为此忽略它，因为在大多数情况下，我是唯一的连接对象，但是即使没有连接，该问题也会不断发生。 处理器几乎总是这样： 我们的例程在夜间运行（没有问题），而某些例程在白天运行。 …

8 sql-server  performance  sql-server-2016  enterprise-edition