PostgreSQL通过RETURNING缓慢地插入单行在生产中花费500毫秒

编程问答 2022-06-10

问题描述

位卡在这里。我有一张叫request_to_print的小桌子。这是表结构。

enter image description here

它具有单个主键request_internal_id。

该表中有747行。

插入时，我注意到它要花费500毫秒以上的时间，这似乎过多。大多数插入操作都是在1毫秒内完成的，并且在更大的表上完成。

'linking'

我已经在类似条件下的测试环境中运行了此命令。因为它是插入内容，所以没有太多要分析/解释的东西。我的意思是，它只是放入一行数据。这是我从跟踪插入内容中得到的：

2020-10-06T10:38:29.284+11:00   Executed DbCommand (566ms) [Parameters=[@p0='',@p1='94ac21e6-bdd5-409c-90f6-4e014d1de763',@p2=NULL (DbType = DateTime),@p3='2020-10-05T23:38:28' (Nullable = true) (DbType = DateTime),@p4='E001'],CommandType='Text',CommandTimeout='30']
2020-10-06T10:38:29.284+11:00   INSERT INTO request_to_print (card_number,customer_internal_id,request_sent_date,requested_date,requesting_store)
2020-10-06T10:38:29.284+11:00   VALUES (@p0,@p1,@p2,@p3,@p4)
2020-10-06T10:38:29.284+11:00   RETURNING request_internal_id;

有人能协助为何在一张小桌子上插入如此看似​​无辜的东西要花这么长时间？就上下文而言，我使用Entity Framework Core 3.1和.NET Core应用程序（通过NPGsql库）执行插入操作。

解决方法

执行计划表明操作已在0.1毫秒内完成；我想那不是执行缓慢。

这里有一些想法可以对此进行调查：

  • 使用auto_explain记录执行缓慢的计划。如果您负担得起大量开销，请将auto_explain.analyze和auto_explain.buffers设置为on，以便该计划告诉您花费的时间。

  • 暂时将deadlock_timeout减小为0.1，并将log_lock_waits设置为on。然后，您将在日志中查看该语句是否被锁定在锁后面。

  • 使用操作系统工具确定I / O系统是否完全过载。

  • 读取日志文件以了解异常情况。

amazon-rds-auroradatabasesqlsql