标签: performance-tuning

我有一个应用程序会生成大量需要快速插入的数据（大约 1300 万条记录）。我使用 JPA 2.0/Hibernate 和 Postgres 9.1，我设法实现了相当好的性能（每秒大约 25k 个插入），通过多线程和每几千个左右插入批量插入，在大约 8 分钟内完成整个运行。

但是，我注意到我有一些缺少索引的外键，我真的希望从分析的角度深入了解数据，并删除特定运行的数据。不幸的是，当我将这 3 个索引添加到获得最多插入的表中时，性能急剧下降到每秒 3k 左右。

有什么办法可以避免这种性能下降？我知道一种选择是在运行之前删除索引并在最后重新创建它们。另一个更笨拙的选择是在文件中生成最大表的数据并使用COPY. 我想我只能在关系中最大的表上执行此操作，因为我需要知道外键值（通过序列生成）。

这两种选择似乎都是黑客。有没有其他解决方案，可能对应用程序的干扰少一点？一些设置告诉 postgres 推迟索引或类似的东西？

欢迎任何想法。

我有一个需要很长时间的删除查询。查看执行计划，我看到删除查询中的大部分估计成本都位于数据模型的一部分中，该部分具有大量数据（例如 400k 行），这看起来不错，但我不明白一件事.

数据模型的精简视图：

table ParentObject 
      int parentObjectId (PK)

table Child
      int childId (PK)
      int parentId (FK)
      <stuff>

table GrandChild
      int grandChildId (PK)
      int childId (FK)
      <more stuff>

其中父对象可能有 200,000 个子对象，而子对象有 2 个左右的 GrandChildren。我对调整以下性能感兴趣：

DELETE FROM ParentObject WHERE parentObjectId = %d;

在 Grandchild 上，(childId, + 两个其他列) 以及主键索引上有一个额外的非聚集索引。在 child 上有一个额外的非聚集唯一索引（parentId，+ 两个其他列）。

我在查询计划中看到的是，在删除 Grandchild 对象时，有两个昂贵的排序操作与删除混合在一起，我不明白它们为什么存在。

我应该注意什么来帮助这个删除操作更快？需要排序吗？如果我对 id 进行非规范化并将父 ID 添加到孙子表中会有所帮助吗？我是否愚蠢地建立了索引？

在充分执行计划是在这里。

我的 PostgreSQL 9.4.1 服务器出现性能问题。我已经使用通常的最佳实践（pgtune + google）调整了服务器。这是相关的配置：

# <snip> the default config above

default_statistics_target = 50
maintenance_work_mem = 960MB
constraint_exclusion = on
checkpoint_completion_target = 0.9
effective_cache_size = 11GB
work_mem = 96MB
wal_buffers = 8MB
checkpoint_segments = 16
shared_buffers = 4GB
max_connections = 200

autovacuum = on
log_autovacuum_min_duration = 10000
autovacuum_max_workers = 5
autovacuum_naptime = 1min
autovacuum_vacuum_threshold = 50
autovacuum_analyze_threshold = 25
autovacuum_vacuum_scale_factor = 0.2
autovacuum_analyze_scale_factor = 0.1
#autovacuum_freeze_max_age = 200000000
autovacuum_vacuum_cost_delay = 20ms
autovacuum_vacuum_cost_limit = -1

#log_statement='mod'
#log_statement='all'

logging_collector = on …

我正在尝试监控无法使用 PerformanceMonitor 跟踪的实时性能数据和使用情况。在生产实时 OLTP 数据库中读取 DMV 的后果是什么？: 例如：sys.dm_tran_locks、sys.dm_os_waiting_tasks、sys.dm_os_performance_counters、sys.dm_exec_connections、sys.dm_io_virtual_file_stats、sys.dm_exec_sql_text 等

我应该在查询 Dmvs 时使用 WITH (NOLOCK) 吗？这会解决许多资源问题吗？在 DMV 中是否有诸如脏读回滚之类的东西。我知道它可以存在于应用程序表中，例如有人提交订单然后取消等。此外，使用 NOLOCK，是否有更高的机会在高容量环境中永远继续，因为我没有锁定行、页面，事情将继续添加到 DMV TableView 中？

谢谢，

假设我们有一个只有一个表的 Postgres 数据库。众所周知，不会在其上运行 UPDATE 语句，也不会运行任何 DELETE。它是 100% 仅附加的。

有些数据库依赖于这种行为并因此设法获得特定的性能提升，例如 Datomic。但是，这不是 Postgres 预期运行的典型方式，所以我想从性能方面受益，我需要专门配置它。

我可以利用我的无更新/删除保证的主要方式是什么？

我相信我可以完全禁用真空，但我不能 100% 确定这一点，而且我认为无论如何这都不是一个巨大的胜利。在这里可以进行的最大配置更改是什么？

如果重要的话，写入每天在特定时间发生一次，而不会在其他时间发生。但是，我认为该细节正在进入“过于本地化”的领域，因此如果没有帮助，我会将其从这个问题中删除。（如果有帮助，我会在这里编辑免责声明部分！）

我们正在使用传统的平面 txt 文件并将它们插入到带有 SSIS 的阶段表中。问题出现了表是否应该具有主聚集键索引。这是没有转换的直接平面文件导入。

create table dbo.CustomerTransaction
(
     CustomerName varchar(255),
     PurchaseLocation varchar(255),
     Productid  int,
     AmountSold float,
     CustomerAddress varchar(50)
)

create table dbo.CustomerTransaction
(
     -- discussion for adding this column
     CustomerTransactionId int primary key clustered identity(1,1) 

     CustomerName varchar(255),
     PurchaseLocation varchar(255),
     Productid  int,
     AmountSold float,
     CustomerAddress varchar(50)
)

-- both tables have nonclustered indexes
create nonclustered index idx_ProductId on dbo.CustomerTransaction(ProductId)
create nonclustered index idx_CustomerAddress on dbo.CustomerTransaction(CustomerAddress)

-- Actually have more indexes, tables above are just for sample 

1）在ETL之前，临时表被截断。没有删除和更新。仅插入。

truncate table dbo.[CustomerTransaction] …

过去几周，我们一直在努力找出导致这些 I/O 问题和检查点变慢的可能原因的根本原因。

乍一看，这显然是 I/O 子系统错误，应该归咎于 SAN 管理员。但最近我们将 SAN 更改为使用全闪存，但截至今天，错误仍然弹出，我不知道为什么，因为我运行的每个指标，无论是等待统计数据还是任何其他指标，都是为了检查 SQL 服务器是否可行罪魁祸首似乎恢复正常。

它并没有真正加起来。也很可能是其他东西正在咀嚼磁盘并且 SQL Server 在这里成为受害者......但我无法找出什么？

数据库位于可用性组中，当这些事件发生时，我们确实会看到角色更改和翻转以及超时发生。

任何帮助解决这个问题将不胜感激。如果需要任何进一步的细节，请告诉我。

错误消息。以下

SQL Server 在数据库 [ABC] (7) 中的文件 [E:\MSSQL\DATA\ABC.mdf] 上遇到了 14212 次 I/O 请求需要超过 15 秒才能完成。操作系统文件句柄是 0x0000000000000D64。最新的long I/O的偏移量为：0x0000641262c000

SQL Server 在数据库 [XYZ] (7) 中的文件 [E:\MSSQL\DATA\XYZ.mdf] 上遇到了 5347 次 I/O 请求需要超过 15 秒才能完成。操作系统文件句柄是 0x0000000000000D64。最新的long I/O的偏移量为：0x0000506c060000

FlushCache：在 925084 毫秒内清理了 111476 个 buf，其中 62224 次写入（避免了 19 个新的脏 buf），用于 db 7:0 平均吞吐量：0.94 MB/秒，I/O 饱和度：55144，上下文切换 98407 最后一个未完成的目标：101241077 次写入FlushCache：在 248687 毫秒内清理了 5616 个 buf，其中 3126 个写入（避免了 3626 个新的脏 buf），用于 …

我有一个具有复杂逻辑和三个深度级别（嵌套视图）的视图。由于复杂，我无法粘贴执行计划。

由于视图的目的是向数据分析师提供一些业务分析，而他们正在开发报告时，他们会通过执行选择（前 N 个）查询来检查视图样本。

视图中的这个（前 N 个）查询执行得非常糟糕，因为优化器正在为此视图选择不同的执行计划（afaik CQScanTopSortNew）

我尝试对顶部 (N) 用例进行一些优化，例如使用哈希连接，但这会破坏非顶部 (n) 用例。

非顶级 (n) 表现良好。我想知道如何防止优化器在具有 top (n) 子句时选择不同的执行计划，而不会显着改变视图的结构或功能。

例如，如果我在视图中添加一个 select distinct ，优化器总是会选择正确的计划，但视图的功能会发生变化。

是否OPTION (RECOMPILE)用于生产？

这个选项似乎受到了很多负面报道。值得吗？

我有一个 DBA，到目前为止，他不喜欢OPTION (RECOMPILE)Report ETL ssis 代理查询的核心思想。这些查询（据我所知）按计划的时间间隔按顺序执行。

回溯历史：

• SQL Server 2016
• 通过 ssis 代理运行时导致聚集索引扫描的 ETL 查询。这些查询需要几分钟才能完成并造成严重影响。
• 通过本地存储过程运行的相同查询和参数在不到一秒的时间内执行。

等等，你确定 OPTION (RECOMPILE) 是答案吗？

• 未知。
• 但是在我尝试之前，我需要知道这是否是一个非常糟糕的主意。

我所知道的风险：

• 过去至少有两个与 OPTION (RECOMPILE) 相关的严重错误。同时运行的两个查询可以交换结果集。呃！！ https://support.microsoft.com/en-us/topic/fix-rare-possibility-of-incorrect-results-when-you-use-option-recompile-for-queries-inside-a-procedure-in- sql-server-2014-or-sql-server-2012-c247fbb5-4125-dd0f-7789-7b1c126f8241

因此，鉴于上述情况 - 该选项是否在现实世界中实际使用？我推荐（并测试）它作为生产环境的一个选项是否可以接受？

我被要求提供更多细节。我提到我确实有其他与此主题相关的帖子。让我提供更多信息：

• 根本问题是来自应用服务器的查询花费的时间超过 60 秒。通常这些查询需要 4 到 10 秒。经过很多痛苦，我确定超时与 ETL 查询一致。15 个查询中有 4 个是具体的。
• 在应用程序服务器中发现了问题的根源。具体来说，隔离级别设置serializable在休眠层内；我了解到，这对于大批量生产环境来说并不是最佳选择。

让我分享其他问题：

SQL Server - 我可以手术删除一个错误的缓存查询计划还是我追求错误的想法？

为什么通过 SSIS 在 ETL 中查询很慢，但通过本地存储过程查询很快？

如标题所述，我开始对表查询进行性能调整，该查询使用由使用 Linq To SQL 作为 ORM 的遗留程序生成的分页。

我发现这个资源强烈建议在分页之前对表进行排序： https: //rimdev.io/optimizing-linq-sql-skip-take/

所以我遵循了提供的建议并尝试了巨大的差异。我很清楚这与 row_number 的计算方式有一定关系，但我不清楚到底发生了什么以及为什么两个查询之间有如此大的差异。

原始慢查询（〜7K元素的数据集，需要〜3s）：

SELECT [t7].[ID], [t7].[ID_BRAND], [t7].[CODE], [t7].[CODFOR], [t7].[COD_ALT01], [t7].[COD_ALT02], [t7].[COD_ALT03], [t7].[ID_UOM], [t7].[IS_ACTIVE], [t7].[_ATTRIBUTES] AS [_ATTRIBUTES], [t7].[_DOCUMENTS] AS [_DOCUMENTS], [t7].[_SEO] AS [_SEO], [t7].[_TRANSLATIONS] AS [_TRANSLATIONS], [t7].[_TAGS] AS [_TAGS], [t7].[_NOTES] AS [_NOTES], [t7].[_METADATA] AS [_METADATA], [t7].[IS_B2B], [t7].[IS_B2C], [t7].[IS_PROMO], [t7].[IS_NEWS], [t7].[CAN_BE_RETURNED], [t7].[IS_SHIPPABLE], [t7].[HAS_SHIPPING_COSTS], [t7].[IS_PURCHEASABLE], [t7].[test], [t7].[ID2], [t7].[CODE2], [t7].[BUSINESS_NAME], [t7].[NAME], [t7].[PHONE_01], [t7].[PHONE_02], [t7].[PHONE_03], [t7].[FAX_01], [t7].[FAX_02], [t7].[COUNTRY_01], [t7].[CITY_01], [t7].[ADDRESS_01], [t7].[COUNTRY_02], [t7].[CITY_02], [t7].[ADDRESS_02], [t7].[EMAIL_01], [t7].[EMAIL_02], [t7].[PEC], [t7].[SITE_01], [t7].[SITE_02], [t7].[SITE_03], [t7].[SITE_04], [t7].[VAT_NUMBER], [t7].[SORT], [t7].[GROUPID_01], [t7].[IS_GROUPLEADER_01], …