凌晨三点的告警，你怕不怕？

先交代下背景。我是个干了二十余年数据库的老兵，PostgreSQL 用了也有七八年。这些年踩过的坑，大概能绕地球半圈——从最基础的索引失效，到让人头皮发麻的锁等待，再到那些“这SQL昨天还跑得挺欢今天怎么就慢成狗”的玄学问题。

说实话，DBA 这活儿，说白了就是个体力活。日常巡检、慢SQL分析、故障排查、容量规划……哪个不是重复性极高、还特费脑细胞的事情？我一度觉得，这行干久了，人也会变得像数据库一样——稳定，但有点呆板。

直到这两年，AI 这玩意儿开始渗透到工作的方方面面。刚开始我也没太当回事，心想你一个写诗的AI，还能帮我修数据库？结果试了几次之后，不得不承认一个扎心的事实：不是AI太强，是我以前太能硬扛了。

今天就聊聊，我作为一个 PostgreSQL DBA，是怎么被 AI“降维打击”，然后又靠着它“起死回生”的。别误会，这不是一篇AI取代DBA的恐吓文，而是一份让你效率翻倍的实战笔记。

PostgreSQL + AI技术学习资料领取

场景一：日常巡检——从“人肉扫描”到“AI找茬”

以前每天早上到工位的第一件事是什么？打开监控面板，看CPU曲线、看IO延迟、看连接数、看慢查询日志。一圈扫下来，少则十分钟，多则半小时。要是赶上服务器多，那基本上一上午就交代给这些花花绿绿的图表了。

这活儿最大的问题是：它不累，但特别烦。 就像让你盯着满墙的蚊子找哪只最胖，眼睛累心更累。

后来我开始试着用 AI 帮忙。做法其实挺土的——把监控脚本的日志输出，直接扔给 DeepSeek 或者 ChatGPT。

以前我写个巡检脚本，输出是这样的：

2026-03-14 08:00:01 - 连接数: 235, 最高峰值: 412

2026-03-14 08:00:01 - 慢查询数量: 17, 平均耗时: 2.3s

2026-03-14 08:00:01 - 死锁次数: 0

2026-03-14 08:00:01 - 缓存命中率: 98.7%

人看这些数字，得在大脑里做一次“阈值对比”：235 连接数正常吗？比昨天高还是低？2.3秒的平均耗时是不是该报警了？

现在我的脚本稍微改了下，输出还是那些数字，但最后多加了一步：把数据发给 AI，让它帮我“找茬”。

我给它设定的提示词很简单：

“你是一个有10年经验的PostgreSQL DBA。以下是某数据库实例今天的早间巡检数据。请帮我判断：1）有没有异常指标；2）如果有，可能的原因是什么；3）建议下一步怎么做。”

AI 给我的回答是这样的：

巡检简报

l 连接数 (235)： 相比昨日同时段(189)上升24%，虽未超阈值，但建议关注应用端是否有连接池配置变更。

l 慢查询 (17个)： 数量偏高。其中有一条 SELECT * FROM orders WHERE user_id = $1 ORDER BY created_at DESC 平均耗时 3.2秒。user_id 字段有索引吗？ 如果没有，这是典型的分页查询性能瓶颈。

l 缓存命中率 (98.7%)： 健康。shared_buffers 配置合理。

建议： 优先排查 user_id 上的索引情况；如果已建索引，考虑是否是排序导致的文件排序。

你看，同样的数据，AI 给的不是“数据”，而是“判断”。它甚至能反向推理出“user_id 有没有索引”这种我本来需要去查表结构才能确认的事情。

从此以后，我的巡检变成了：

1、脚本跑数据

2、AI 出报告

3、我直接看结论，有问题的再去深挖

效率翻倍？我觉得不止。关键是脑子解放出来了，不用再当人肉阈值报警器。

场景二：SQL优化——被AI按在地上摩擦

这事儿说起来有点丢人，但确实发生了。

那天开发扔过来一条 SQL，说跑了好几分钟出不来，让我看看。我扫了一眼，标准的关联查询，三张表，where 条件里有个 LIKE '%xxx%'。经验告诉我，这种模糊查询基本别想走索引，大概率全表扫了。

我正准备打开 EXPLAIN ANALYZE 看执行计划，忽然想起最近总听说 AI 能写 SQL、改 SQL，要不试试让它先看看？

我把 SQL 和表结构（大概的字段名和类型）一起扔给了 AI，问它：“这条SQL怎么优化？”

十几秒后，AI 给我回了长长的一段，我提炼一下核心：

1. 问题定位： LIKE '%xxx%' 导致索引失效，建议改成全文检索（如果用到了文本搜索场景）。

2. 执行计划推演： 如果数据量在百万级，现在的写法会走 Seq Scan，加上 Nest Loop，复杂度 O(N2)。

3. 改写建议： 如果业务允许，改成 LIKE 'xxx%' 让索引生效；或者考虑使用 pg_trgm 插件建立 GIN 索引，支持模糊查询加速。

4. 顺手还给了个索引创建语句： CREATE INDEX CONCURRENTLY idx_table_col_gin ON table USING gin (col gin_trgm_ops);

我当时就有点懵。不是因为我不知道 pg_trgm，而是它在一分钟之内，把从“问题诊断”到“解决方案”的完整链路给我跑通了，还附带索引语法。

换我自己干呢？

l EXPLAIN 看执行计划（2分钟）

l 分析全表扫的原因（1分钟）

l 查文档确认 pg_trgm 的语法（如果记不清的话，3-5分钟）

l 跟开发沟通确认能否改 SQL（不定时）

l 写完索引，再 EXPLAIN 验证（2分钟）

AI 干这事儿，十几秒，零误差。

从那天起，我养成了一个习惯：任何慢 SQL 到我手里，先不急着 EXPLAIN，先让 AI 扫一眼。不是为了偷懒，是 AI 有时候真能想到一些我没想到的角度——比如某些冷门的插件，或者索引覆盖的奇技淫巧。

场景三：故障排查——和AI打配合战

故障排查这事儿，最怕的是什么？不是问题有多难，而是信息太多，不知道从哪看起。

有一次线上出问题了，应用端反馈“某些接口响应超时”。我登录到数据库服务器，top 一看，CPU 不高；iostat 一看，IO 也不忙；pg_stat_activity 一看，连接数正常，也没有长期 running 的事务。

这就尴尬了。指标都正常，但用户说慢。就像去医院检查，所有指标都正常，但你人就是难受。

我习惯性地把当时的 pg_stat_activity 输出、最近几分钟的慢查询日志，以及几个关键性能视图（比如 pg_stat_bgwriter、pg_stat_database）的数据，整理成一个文本文件，扔给了 AI。

我说：“所有基础指标都正常，但应用反映响应慢。帮我看看这些数据里有没有什么被我忽略的线索。”

AI 扫了几秒钟，给我指出一个细节：

注意到 pg_stat_bgwriter 中的 checkpoints_timed 和 checkpoints_req 比例异常。

通常情况下，定时 checkpoint（checkpoints_timed）应该远多于请求式 checkpoint（checkpoints_req）。但你的数据显示，checkpoints_req 占比过高。这意味着系统频繁因为“需要写入的数据量达到 max_wal_size”而触发强制 checkpoint，这会瞬间产生大量 IO 写操作，虽然你的 IO 延迟不高，但突发的 IO 毛刺可能导致应用端请求短暂排队。

建议：适当调大 max_wal_size，或者检查是否有大事务频繁写入导致 WAL 激增。

我顺着这个思路一查，果然，某业务在做数据批量导入，每5分钟写一次大事务，正好踩在 checkpoint 的临界点上。调大 max_wal_size 后，问题消失。

这事给我的触动挺大的。AI 不是神，它不能替我干活，但它能在我“灯下黑”的时候，帮我指一条我没看到的路。 那些被我忽略的关联关系，那些藏在数字背后的逻辑，AI 比人眼更擅长发现。

场景四：容量规划——AI帮我“算命”

容量规划这事儿，说好听点叫“前瞻性规划”，说难听点就是“算命”——根据现在的数据增长趋势，猜未来什么时候磁盘会满、什么时候 CPU 会扛不住。

以前怎么做？Excel 拉个趋势线，或者自己写脚本算增长率，然后凭经验拍个脑袋：“这个季度磁盘还能撑住，下个季度得扩容。”

但数据库的增长从来不是线性的。业务搞个活动，流量翻倍；某个新功能上线，写入量暴涨。靠历史趋势推算未来，就像看后视镜开车。

现在我每周会把过去一个月的监控数据（磁盘使用率、CPU 负载、连接数峰值、事务吞吐量）喂给 AI，让它帮我“算一卦”。

我的提示词是：

“基于过去30天的 PostgreSQL 性能数据，预测接下来两周的磁盘使用率和连接数峰值。请标注出哪些指标可能在未来两周内达到预警阈值，并给出扩容建议。”

AI 不仅能给出预测数值，还会提醒我一些潜在风险：

n 磁盘使用率： 当前 65%，按日均增长 1.2% 计算，预计 4 月 1 日突破 80%（建议预警），4 月 9 日突破 90%（风险）。如果下周有批量导入任务，请提前调整。

n 连接数： 近期峰值 450，距离 max_connections 的 800 还有空间。但注意应用端有连接池，实际活跃连接可能翻倍，建议关注应用日志。

有了这个，我再跟老板汇报“我们下个月要加磁盘”的时候，不再是凭感觉说“我觉得快满了”，而是能甩出一句：“AI 预测下月 9 号磁盘到 90%，最晚下月初得扩容。”

这事儿听起来玄乎，其实逻辑很简单：AI 擅长从历史数据里找规律，而 DBA 负责判断这些规律在业务逻辑上是否成立。我俩配合，一个算命，一个解卦，刚刚好。

AI 没说的，还得靠人

说了这么多 AI 的好话，你也别误会。AI 不是万能的，它只是个工具，而且是个经常犯傻的工具。

比如 AI 给的 SQL 优化建议，有时候在测试环境跑得飞快，上生产就崩——因为它不知道你的数据分布有多偏，不知道你的硬件配置有多老，不知道你的业务高峰期是什么时候。

再比如故障排查，AI 能给你一万个可能的原因，但最终拍板的，还得是你自己。AI 擅长“发散”，人类擅长“收敛”。

所以我现在的工作方式变了：

l 脏活累活（巡检、数据收集） → AI 干

l 需要脑洞的（查原因、找方向） → AI 帮着干

l 需要拍板的（选方案、调参数、上线执行） → 我自己干

效率确实翻倍了，但人没失业，反而比以前更忙——因为腾出来的时间，可以去学更多新东西，去处理那些真正复杂的问题。

写在最后

如果你问我，一个 PostgreSQL DBA 会不会被 AI 取代？

PostgreSQL + AI技术学习资料领取

我的答案是：只会用工具的 DBA 可能会被取代，但会驾驭工具的 DBA 永远不会。

就像当年从命令行走到图形界面，从手工运维走到自动化运维，每一次工具的跃迁，淘汰的都不是“人”，而是“不愿意改变的人”。

AI 这波浪潮，本质上就是把我们从那些重复、枯燥、费脑的体力活里解放出来，让我们有机会去做点更值钱的事——比如理解业务、设计架构、预判风险。

如果你也想在这一波浪潮里站稳脚跟，不被拍在沙滩上，除了学会用 AI，更重要的还是把 PostgreSQL 的内功练扎实。

顺便提一嘴，重庆思庄的数据库学习课程里，最近也加入了 AI 辅助 DBA 实战的内容。 如果你想系统性地学习怎么把 AI 用得更顺手，顺便把 PostgreSQL 底子打牢，可以去看看。不是广告，是真觉得这种“人+AI”的打法，值得更多人知道。

毕竟，未来属于那些既懂数据库，又会用 AI 的人。

P.S. 下次遇到数据库问题，别急着先开干，试试先问一句 AI：“你怎么看？” 也许会有惊喜。