OpenAI vs DeepSeek：数据库诊断能力

原文地址：https://coroot.com/blog/engineering/using-ai-for-troubleshooting-openai-vs-deepseek

ALTER TABLE ... SET body NOT NULL

目前的效果很好，但 Coroot 需要太多脑力和理解复杂系统中因果关系的能力。最终目标应该是像你所做的那样，让 Coroot 提供具体的叙述性解释。

答案是：

1. 查询延迟增加：

• Postgres 平均查询延迟激增，尤其是 pg-cluster-2。

• ALTER TABLE 语句（alter table articles alter column body set not null）消耗了大量 I/O，如 I/O 时间查询图所示。

• Postgres 连接图显示锁定连接急剧增加。

• 锁定查询图证实，由于 ALTER TABLE 操作，查询被阻塞。

• 阻塞查询图显示 ALTER TABLE 查询持有锁并阻塞了多个其他查询。

• 复制滞后显示了一个峰值，可能是由于 ALTER TABLE 操作造成了写入积压。

为什么？

• ALTER TABLE ... SET NOT NULL 是一种全表操作，需要进行全表扫描，以确认没有现有记录违反新约束。
• 它会锁定整个表，在操作完成前阻止写入/读取。
• 这在频繁读/写的高负载环境中尤其容易出现问题。

SELECT pg_terminate_backend(pid) FROM pg_stat_activity WHERE query LIKE '%ALTER TABLE articles alter column body set not null%';

SELECT * FROM pg_stat_activity WHERE wait_event IS NOT NULL;

步骤 1：添加检查约束（非阻塞）

ALTER TABLE articles ADD CONSTRAINT articles_body_not_null CHECK (body IS NOT NULL) NOT VALID;

步骤 2：回填缺失值（如果有）

步骤 3：验证约束条件（仍为非阻塞）

ALTER TABLE articles VALIDATE CONSTRAINT articles_body_not_null;

步骤 4：如果不存在违规行为，则更改该列

ALTER TABLE articles ALTER COLUMN body SET NOT NULL;

pg_repack -t articles --dbname=mydatabase

3.  在低流量时段执行 schema 变更

生产环境中，在维护窗口期间执行 schema 变更以减少影响。

4. 对大型表进行分区

对于频繁更改的大型表，可考虑分区，以便在较小的分段上隔离操作。

结论

ALTER TABLE 操作锁定了文章表，导致严重的查询延迟和复制滞后。最好的办法是：

• 如果造成停机，取消操作

• 使用在线安全替代方法（检查约束 + 验证）

• 谨慎安排 schema 变更

我们正在把 AI 集成到 Coroot 中，但不会使用截图，因为用程序解释复杂的系统参数要简单得多。

LLM 能够「理解」我们的领域，并生成具有可操作性见解的深度总结，这令人兴奋。然而，依赖单一供应商似乎并不是一个稳健的解决方案。

幸运的是，DeepSeek 已经成为 OpenAI 模型的有力替代品，尤其是最近发布的 R1 模型。DeepSeek 的开源特性也让我们在需要时可以选择自托管，不过这暂时不在我们的计划之内。

现在，让我们使用 DeepSeek-R1 重复实验：

DeepSeek-R1

答案是：

数据显示 pg-cluster-2 中存在严重的性能问题，主要原因是文章表上的 ALTER TABLE 命令长时间运行。该操作导致表锁定，阻塞其他关键查询（如 SELECT 和 INSERT），从而导致  

- 高查询延迟（10-15 秒）

- 活动/锁定连接激增

- 查询吞吐量下降

- 其他集群的复制滞后（轻微） 

根本原因

ALTER TABLE 语句（alter table articles alter column body set not ?）  

• 对文章表持有独占锁

• 阻塞后续查询（如 SELECT、INSERT）

• 创建一连串等待查询，增加了延迟和连接使用 

-- Find the PID of the ALTER TABLE query     SELECT pid, query FROM pg_stat_activity WHERE query LIKE '%alter column body%';     -- Terminate it     SELECT pg_terminate_backend(<PID>);

注意：确保不会损坏数据（例如，如果 ALTER 是迁移的一部分）。

2.  重新安排 DDL 操作： 

在低流量时段运行 schema 变更，或使用在线 DDL 工具，如  

- pg_repack（在没有锁的情况下重建表）

- CREATE INDEX CONCURRENTLY（针对与索引相关的更改）

3.  优化 ALTER 表： 

要将列设置为 NOT NULL，确保它已不包含 NULL 值。预运行：

UPDATE articles SET body = '' WHERE body IS NULL;  -- Example cleanup

SET LOCAL lock_timeout = '5s';     ALTER TABLE ...;

- 优化 'SELECT id FROM articles WHERE created < ? ...' 查询，并为 created 创建索引。 

阻塞 ALTER TABLE 是关键问题。首先通过终止或重新安排操作来解决这个问题，然后实施保障措施来避免类似事件。优化查询，并使用无锁定 DDL 工具进行未来的 schema 变更。

是的，但前提是有足够的数据来描述系统行为。