小编The*_*Sky的帖子

我有一个已ON DELETE NO ACTION定义的现有外键。我需要将此外键更改为ON DELETE CASCADE. 我可以在交易中做到这一点：

begin;
alter table posts drop constraint posts_blog_id_fkey;
alter table posts add constraint posts_blog_id_fkey foreign key (blog_id) references blogs (id) on update no action on delete cascade;
commit;

问题是该posts表很大（400 万行），这意味着验证外键可能需要很长的时间（我已经用数据库的副本对此进行了测试）。滴/添加外键获取的ACCESS EXCLUSIVE锁上posts。因此，添加外键会在相当长的时间内阻止对表的所有访问，posts因为在发生约束验证时会持有锁。我需要执行在线迁移（我没有专门的停机时间窗口）。

我知道我可以执行2 个事务来帮助检查需要很长时间：

begin;
alter table posts drop constraint posts_blog_id_fkey;
alter table posts add constraint posts_blog_id_fkey foreign key (blog_id) references blogs (id) on update no action …

我有一个由生产应用程序使用的数据库。它是 Amazon RDS 上的 db.m3.medium。我们注意到，许多查询开始变慢，而通常情况下不应变慢（例如按主键选择行）。

我们开始调查这个问题，发现我们select 1对数据库的健康检查也很慢。例如，以下是explain (analyze buffers) select 1大约 20 小时内每秒运行的一些图表：

持续时间（往返时间）（毫秒）

我将 y 轴的上限设置为 500 毫秒。

规划（毫秒）

我将 y 轴的上限设置为 100 毫秒。

执行（毫秒）

我将 y 轴的上限设置为 100 毫秒。

计划一个查询要花费如此极端的时间，这似乎很疯狂。

当我们从整体上查看数据库时，似乎没有任何迹象表明它承受着足够重的负载。这是典型的一天：

中央处理器

读取（蓝色）/写入（紫色）吞吐量 (MiB/s)

网络传输（紫色）/接收（蓝色）吞吐量（KiB/s）

磁盘

磁盘大小为 30 GiB，已使用 5.75 GiB。

记忆

有 3.75 GiB 的 RAM，还有 2.2 GiB 是免费的。

该数据库实例是自 2017 年 12 月 17 日起的新实例（由于需要 AWS 维护而从另一个实例进行手动故障转移之后）。我们的假设是单核导致操作系统（和 Postgres）出现上下文切换问题。然而，数据库的任何指标都没有真正表明它运行得非常热。我还可以确认我们没有任何长时间运行的查询/交易。

什么可能导致简单查询（例如select 1规划和执行时间较长）？