“一顿海鲜引发”（1）：DBA、架构师与数据库运维工具的爱恨情仇

liuaustin32025年10月20日约 15 分钟

❝
开头还是介绍一下群，如果感兴趣PolarDB ,MongoDB ,MySQL ,PostgreSQL ,Redis, OceanBase, Sql Server等有问题，有需求都可以加群群内有各大数据库行业大咖，可以解决你的问题。加群请联系 liuaustin3 ，（共3300人左右 1 + 2 + 3 + 4 +5 + 6 + 7 + 8 +9）(1 2 3 4 5 6 7群均已爆满，开8群近400 9群 200+，开10群PolarDB专业学习群100+)

最近一个前同事联系我，问我有没有好的DBA可以推荐一下，我说你们金融机构还找不到人，分分钟一个招聘那不得挤破脑袋。前同事回我一句，好的不好招，现在着急，有没有。我说你找XXX不就行了，问问他。前同事回我，他要的太高，package不够他的要求。你还有别的人推荐吗？

这一时到也是问住我了，现在好的DBA大多不动地方，世道不好，有个还不错的地方就不愿意动了。一般的就他们公司那个挑挑拣拣的，又是学历，又是年龄，又是工作经验，我往哪给你找去，一个人干8个人的活，还一堆领导抓考勤,开各种垃圾会，就是是个名头金融机构，不过说回来他们为什么最近招人，我到时好奇？

当时脑子不知道是怎么回事，我就随口说了一句，你们现在用什么工具来做一些DBA的日常工作，可算惹祸了。他说以前都是他们DBA自己写的程序，现在有一部分功能不是太好用，还等着优化呢，这不最近企业响应国家号召，企业走出去，境外业务开展了，但人没有随着业务量的上升而同步增加，现在他们金融机构的DBA都火大，工资没涨，活更多了。

“其实你们应该买一套数据库运维工具，来管理你们的数据库”，我敷衍的问他，想快速结束这个话题，我手里还一堆活呢。

然后就出事了，他一个架构师非要我给他推荐数据库运维管理软件，他说他也不懂，不过这活可没有白干的，说请我吃海鲜，行吧冲着海鲜拼了，给他找个靠谱的数据库运维软件，顺便也了解一下当前数据库运维软件的行情。

从一个DBA的角度来分析，大部分日常工作和问题解决都围绕着SQL，SQL的运行效率，60%的数据库问题都发生在日常的SQL运行中，这里包含什么问题

1 开发撰写语句并不能完全遵守，SQL撰写规范的问题，很多情况，规范好订立，但执行很困难。

2 SQL语句在运行一段时间后，随着数据量的上升，性能日益变差的问题，不定那天就容易出事。

3 SQL语句的改写和缺失索引的补充的问题

4 紧急情况下，快速分析和解决SQL问题，这里提到的就是快速分析的数据库定位问题的能力。

总之，DBA的大部分日常运维问题，和SQL有关的多，SQL的审计，SQL的性能解决，以及数据库日常的监控和SQL语句的分析，锁分析等等，那就照着解决这个问题的方式来找软件。所幸我想起来前些日子参加了DTCC大会，其中有一个专门做这方面的工具的厂家。然后我就把会上这个厂家的PPT发给前同事，后面就等着他请我吃海鲜，心里想着去哪里宰他。

当天晚上他就打来电话，我以为是约我吃饭，这家伙上来就质问我。

架构师前同事：老刘你这不够揍，就给我一个PPT就完了，我要的是一个经验丰富的DBA，不是一个破软件。

我：不是PPT上不是写的很清楚吗？怎么不行了？什么叫破软件

架构师前同事：不是，我要解决问题的，能出事给我找问题的，一个软件能干这事情吗？

我：怎么不能了，19页，这不有吗？出了问题，一分钟能给你进行诊断

19页

架构师前同事：一分钟给我诊断，我自己写软件就能诊断，我用他。

我: 你自己诊断，我请问你，如果是死锁的问题产生的卡顿，如果是刚上线，产生的少量blocked，如果是这些综合问题，产生的数据库性能下降，导致的原本不是慢查询的SQL，变成慢SQL，这都是写个软件就能解决了。那你还需要DBA ，你自己干得了。

架构师前同事：有那么复杂吗？不就一个慢SQL吗？

我：你要这样说怎么就的好好聊1000块钱的，我请问你，你系统一个SQL平均以每6秒的速度，运行一次会产生系统的资源告警吗？你没有告警你会发现潜在的问题的，今天一个6秒，明天一个4秒，业务多了访问多了，6秒某天变成60秒了，请问这是为什么？还是那个SQL的问题？？？？

架构师前同事：那你说为什么？不就破SQL，有什么大不了，不行我们就拿出来，用JAVA跑。

我：你呀，骗鬼呢，今天一个6秒SQL，换成程序，明天一个4秒换成程序，你干脆用SQLite 多好，用什么数据库。

架构师前同事：那你说我怎么辨别问题？

我：海鲜请定了对吧，OK，我来教教你。综合问题综合分析，你出问题的时候的 CPU,内存，磁盘IO，以及链接数这些数据你是不是的汇总，放到一起，然后定位到你发生问题一个范围比如你 10点发生的问题，你去看你的监控上9:50 到 10:10分之间的一个性能曲线，你10点的问题未必就是10点开始，很可能在之前一直积累，比如一个慢SQL在9：50开始的，你10点正好业务高峰期，然后性能累加，导致你CPU性能消耗高。

架构师前同事：所以呢？

我：所以解决数据库问题，不是看单个点的问题，你要从你发生的问题点，往前找根因，所以你必须得有一个可以查看历史数据库性能分析的监控软件OK ，还写个软件。

架构师前同事：那你给我举一个例子，说明你牛逼

我：来看下面这个图，你能看出点什么，你就给我看这张图，我问你数据库CPU 为嘛高？

架构师前同事：我怎么知道？

我：人家不告诉你了一分钟解决问题，看CPU异常，把鼠标放到异常上，下面就会出现在这期间运行的SQL。你勾选这个SQL然后直接点击SQL，就出现下面的的根因分析了。

架构师前同事：行呀，这这么快就分析出问题了。

我：还用我分析，你往下点，发生问题的根因都写出来了。

架构师前同事：这么就分析出来原因了？什么问题？

我：突发的高频次的SQL访问导致，很多情况下并不是SQL本身慢，或者是慢SQL，而是你的并发太高导致，而这部分不少情况下，分析会耗费时间，在发现问题同时，还给出了INDEX的索引优化建议，通过添加索引可以提高高并发时的SQL TPS，另外SQL审核在整体的软件开发中也很重要，这点你应该比我清楚对吧。

架构师前同事：SQL审核，不就是看看SQL写的业务逻辑别有问题，该加索引加索引不就完了。

我：2000快了，在和你唠1000块的，看下面这个图，你们公司不应该有上线规范吗？执行DDL，DML语句不应该有审核吗？总不能开发自己连生产数据库吧，一些SQL在测试的时候就发现问题，在测试的时候就应该进行先期的优化，OK。