Questions tagged «performance»

我一直在阅读有关Kimberly Tripp的一些有关SQL Server计划缓存的精彩文章，例如：http : //www.sqlskills.com/blogs/kimberly/plan-cache-and-optimizing-for-adhoc-workloads/ 为什么甚至有“针对临时工作负载进行优化”的选项？这不应该一直都在吗？无论开发人员是否在使用即席SQL，为什么不在每个支持它的实例（SQL 2008+）上都启用此选项，从而减少缓存膨胀？

49 sql-server  performance  query-performance  memory  cache 

MySQL在varchar大小之间是否存在性能差异？例如varchar(25)和varchar(64000)。如果不是，是否有理由不声明所有具有最大大小的varchar，只是为了确保您不会用完空间？

45 mysql  performance  datatypes  varchar 

概念性问题：单个查询的速度是否比联接更快？或者：我是否应该尝试将客户端上想要的每个信息都压缩到一个 SELECT语句中，或者仅使用看起来方便的数量？ TL; DR：如果我加入的查询花费的时间比运行单个查询所花费的时间更长，这是我的错还是应该这样？ 首先，我不是非常了解数据库，所以可能只是我一个人，但是我注意到当我必须从多个表中获取信息时，通过对单个表进行多次查询来获取此信息“通常”更快（也许包含一个简单的内部联接）并在客户端将数据修补在一起，以尝试编写一个（复杂的）联接查询，在此我可以在一个查询中获得所有数据。 我试图将一个非常简单的示例放在一起： SQL小提琴 模式设置： CREATE TABLE MASTER ( ID INT NOT NULL , NAME VARCHAR2(42 CHAR) NOT NULL , CONSTRAINT PK_MASTER PRIMARY KEY (ID) ); CREATE TABLE DATA ( ID INT NOT NULL , MASTER_ID INT NOT NULL , VALUE NUMBER , CONSTRAINT PK_DATA PRIMARY KEY …

44 performance  join  tuning  application-design 

我继承了执行以下任务的维护计划： 清理旧数据 检查数据库完整性 执行数据库和事务日志备份 重组我们的索引 更新统计 删除旧的备份和维护计划文件 在23分钟的维护计划中，更新统计信息需要花费惊人的13分钟。在这13分钟内，对数据库的访问被阻止（或至少暂停了从该数据库到我们其他数据库的复制）。 我的问题是： 我们什么时候应该更新统计信息，为什么？ 这似乎是我们每天应该减少的工作频率。我试图让我们摆脱“不必要”维护不必要的思维定势。

42 sql-server  performance  maintenance  statistics 

我很久以前就读过书。本书指出，我们不应允许在SQL Server中具有嵌套视图。我不确定为什么不能这样做，否则我可能会记得错误的陈述。 学生们 SELECT studentID, first_name, last_name, SchoolID, ... FROM students CREATE VIEW vw_eligible_student AS SELECT * FROM students WHERE enroll_this_year = 1 教师 SELECT TeacherID, first_name, last_name, SchoolID, ... FROM teachers CREATE VIEW vw_eligible_teacher AS SELECT * FROM teachers WHERE HasCert = 1 AND enroll_this_year = 1 学校 CREATE …

42 sql-server  performance  database-design  view 

我试图让PostgreSQL主动自动清理数据库。我目前已将自动吸尘配置如下： autovacuum_vacuum_cost_delay = 0＃关闭基于成本的真空 autovacuum_vacuum_cost_limit = 10000＃最大值 autovacuum_vacuum_threshold = 50＃默认值 autovacuum_vacuum_scale_factor = 0.2＃默认值 我注意到只有在数据库未处于负载状态时才会启动自动清理功能，因此我遇到了这样的情况：死元组比活动元组多得多。有关示例，请参见随附的屏幕截图。其中一张桌子有23个活动元组，但有16845个死元组正在等待真空。太疯狂了！ 当测试运行完成并且数据库服务器处于空闲状态时，自动吸尘器将启动，这不是我想要的，因为当失效的元组的数量超过20％的活动元组+ 50时，我希望自动吸尘器启动，因为数据库已经配置。服务器空闲时自动清理对我来说毫无用处，因为生产服务器在持续的时间内有望达到每秒数千次的更新，这就是即使服务器负载时我也需要运行自动清理的原因。 有什么我想念的吗？在服务器负载较重时，如何强制自动吸尘器运行？ 更新资料 难道这是一个锁定问题？有问题的表是汇总表，这些表是通过插入后触发器填充的。这些表被锁定为SHARE ROW EXCLUSIVE模式，以防止并发写入同一行。

42 postgresql  performance  performance-testing  vacuum 

我遇到了一个奇怪的问题，即SQL Server 2016 Standard Edition 64位似乎已经限制了为其分配的总内存的正好一半（128 GB的64GB）。 输出@@VERSION为： Microsoft SQL Server 2016（SP1-CU7-GDR）（KB4057119）-13.0.4466.4（X64）2017年12月22日11:25:00版权所有（c）Windows Server 2012 R2 Datacenter 6.3上的Microsoft Corporation标准版（64位）（内部版本9600：）（管理程序） 输出sys.dm_os_process_memory为： 当我查询时sys.dm_os_performance_counters，我看到Target Server Memory (KB)处的131072000，Total Server Memory (KB)位于处的一半65308016。在大多数情况下，我认为这是正常现象，因为SQL Server尚未确定它需要为其自身分配更多的内存。 但是，它已经“卡住”了〜64GB，已经超过2个月了。在此时间段内，我们对某些数据库执行了大量内存密集型操作，并向实例添加了近40个数据库。我们共有292个数据库，每个数据库都有4GB的预分配数据文件（自动增长速率为256MB）和2GB的日志文件的自动增长速率为128MB。我每晚晚上12:00执行一次完整备份，并从星期一到星期五从6:00 AM到8:00 PM（每15分钟间隔）开始事务日志备份。这些数据库的整体吞吐量相对较低，但是我怀疑SQL Server尚未爬到Target Server Memory 很自然地会通过添加新数据库，正常查询执行以及已运行的占用大量内存的ETL管道来实现。 SQL Server实例本身位于虚拟化（VMware）Windows Server 2012R2服务器之上，该服务器具有12个CPU，144GB内存（128GB到SQL Server，16GB预留给Windows）以及总共4个虚拟磁盘，这些虚拟磁盘位于具有15K SAS驱动器的vSAN之上。Windows自然位于64GB C：磁盘上，页面文件为32GB。数据文件位于2TB D：磁盘上，日志文件位于2TB L：磁盘之上，而tempdb位于256GB T：磁盘上，其中8x16GB文件没有自动增长。 我已验证除之外，服务器上没有其他SQL Server实例在运行MSSQLSERVER。 该服务器完全专用于SQL Server实例，因此我们没有在其上运行的其他任何可能消耗内存的应用程序或服务。 我利用RedGate SQL …

39 sql-server  performance  sql-server-2016  memory  sp-blitz 

TL; DR 由于这个问题一直在引起人们的关注，因此在这里我将对其进行总结，这样新来的人就不必经历历史了： JOIN table t ON t.member = @value1 OR t.member = @value2 -- this is slow as hell JOIN table t ON t.member = COALESCE(@value1, @value2) -- this is blazing fast -- Note that here if @value1 has a value, @value2 is NULL, and vice versa 我意识到这可能不是每个人的问题，但是通过强调ON子句的敏感性，它可以帮助您朝正确的方向看。无论如何，原始文本在这里供将来的人类学家使用： 原文 …

39 sql-server  performance 

假设生产OLTP系统主要包含InnoDB表 错误/配置错误的系统的常见症状是什么？ 您最常更改哪些配置参数的默认值？ 在出现问题之前，您如何发现潜在的瓶颈？ 您如何识别和解决活动中的问题？ 任何详述特定status变量和诊断的轶事都将不胜感激。

39 mysql  performance  innodb 

我在某些具有较大可能结果集的数据库查询中遇到性能问题。 有问题的查询，我AND在WHERE子句中有三个 条款的顺序重要吗？ 与之类似，如果我将ASI_EVENT_TIME子句放在第一位（因为这样会从所有子句中删除大部分结果。 这会改善查询的运行时间吗？ 查询： SELECT DISTINCT activity_seismo_info.* FROM `activity_seismo_info` WHERE activity_seismo_info.ASI_ACTIVITY_ID IS NOT NULL AND activity_seismo_info.ASI_SEISMO_ID IN (43,44,...,259) AND ( activity_seismo_info.ASI_EVENT_TIME>='2011-03-10 00:00:00' AND activity_seismo_info.ASI_EVENT_TIME<='2011-03-17 23:59:59' ) ORDER BY activity_seismo_info.ASI_EVENT_TIME DESC 查询说明： +----+-------------+---------+-------+---------------------------+--------------+---------+------+-------+-----------------------------+ | id | select_type | table | type | possible_keys | key | key_len | ref …

38 mysql  performance  mysql-5 

RAM的重要性已被确​​定，但是关于MySQL使用CPU时，关于内核和多线程的重要性的资料很少。我说的是在4cores，6cores和8cores等上运行MySQL的区别。 不同的存储引擎对CPU的使用是否不同？

38 mysql  performance 

在Ubuntu 12.04上使用PG 9.1。 目前，我们最多需要24小时才能在数据库上运行大量的UPDATE语句，其形式为： UPDATE table SET field1 = constant1, field2 = constant2, ... WHERE id = constid （我们只是覆盖由ID标识的对象的字段。）这些值来自外部数据源（尚未存在于表的DB中）。 该表每个都有少量索引，没有外键约束。直到结束都不会进行COMMIT。 导入pg_dump整个数据库需要2小时。这似乎是我们应该合理定位的基准。 缺少生成自定义程序以某种方式为PostgreSQL重新构造数据集以重新导入的方法，我们是否可以做些什么使批量UPDATE性能更接近于导入？（这是我们认为日志结构的合并树可以很好处理的一个区域，但是我们想知道PostgreSQL中是否可以做任何事情。） 一些想法： 删除所有非ID索引并随后进行重建？ 增加checkpoint_segments，但这实际上有助于持续的长期吞吐量吗？ 使用这里提到的技术？（将新数据作为表加载，然后“合并”在新数据中找不到ID的旧数据） 基本上，有很多事情可以尝试，我们不确定最有效的是什么，或者我们是否忽略了其他事情。我们将在接下来的几天中进行实验，但我们也想在这里提出问题。 我确实在表上有并发负载，但是它是只读的。

37 postgresql  performance  update  bulk 

使用SQL Server 2005。 我正在执行巨大的DELETE FROM而没有where子句。它基本上等效于TRUNCATE TABLE语句-除了不允许使用TRUNCATE。问题是表很大-一千万行，而且要花一个多小时才能完成。有没有什么办法可以使其更快而没有： 使用截断 禁用或删除索引？ t日志已经在单独的磁盘上。 任何建议欢迎！

37 sql-server  performance  delete 

背景 我有一个针对SQL Server 2008 R2的查询，该查询联接和/或左联接约12个不同的“表”。该数据库相当大，有许多表超过5000万行和大约300个不同的表。适用于在全国设有10个仓库的大型公司。所有仓库都读取和写入数据库。所以它很大而且很忙。 我遇到的查询看起来像这样： select t1.something, t2.something, etc. from Table1 t1 inner join Table2 t2 on t1.id = t2.t1id left outer join (select * from table 3) t3 on t3.t1id = t1.t1id [etc]... where t1.something = 123 请注意，联接之一是在不相关的子查询上。 问题是从今天早上开始，在没有对系统进行任何更改（我或我的团队中的任何人都知道）的情况下，该查询通常需要运行2分钟左右，而开始需要花一个半小时才能运行-跑了。数据库的其余部分运行正常。我已经从通常运行该程序的过程中取出了此查询，并以相同的慢度在带有硬编码参数变量的SSMS中运行了该查询。 奇怪的是，当我使用不相关的子查询并将其放入临时表中，然后使用该子查询代替子查询时，查询运行良好。另外（这对我来说是最奇怪的），如果我将这段代码添加到查询的末尾，则查询运行良好： and t.name like '%' 我从这些小实验得出的结论（可能是错误的）是，放慢速度的原因是由于如何设置SQL的缓存执行计划-当查询略有不同时，它必须创建一个新的执行计划。 我的问题是这样的：当以前运行快速的查询突然在深夜开始运行，并且除此查询外没有其他影响，我该如何解决它以及如何避免将来发生？我怎么知道SQL在内部做的事情使其变得如此缓慢（如果运行了错误的查询，我可以得到它的执行计划，但它不会运行-也许预期的执行计划会给我一些东西？）？如果此问题与执行计划有关，那么如何避免SQL认为真正糟糕的执行计划是个好主意？ 同样，这也不是参数嗅探的问题。我以前见过这种情况，不是这样，因为即使我在SSMS中对变量进行硬编码，性能仍然很慢。

36 sql-server  performance  sql-server-2008 

我经常阅读何时必须检查行是否存在的情况，应该始终使用EXISTS而不是COUNT来完成。 但是，在最近的几种情况下，我测量了使用count时的性能提升。 模式如下： LEFT JOIN ( SELECT someID , COUNT(*) FROM someTable GROUP BY someID ) AS Alias ON ( Alias.someID = mainTable.ID ) 我不熟悉SQL Server内部“发生什么”的方法，因此我想知道EXISTS是否存在未预料到的缺陷，该缺陷对我所做的测量完全有意义（EXISTS是RBAR吗？！）。 您对此现象有一些解释吗？ 编辑： 这是您可以运行的完整脚本： SET NOCOUNT ON SET STATISTICS IO OFF DECLARE @tmp1 TABLE ( ID INT UNIQUE ) DECLARE @tmp2 TABLE ( ID INT …

35 sql-server  performance