关于 DBA 这个角色职业未来之我见

我自己对 DBA 角色的理解来自于之前长期同时兼开发和数据库运维两种岗位。从风险控制角度看这种职责安排铁定是不合规了，但长期的兼任确实会产生更全面的看法。

DBA 这个角色一般是从各种 IT 管理框架的定义出发去理解，包括 COBIT、ITIL 以及等级保护都有数据库管理员这个角色的安排，定义上大致相同，但并不很清晰。

如果从粗略意义上看，拿着数据库系统管理员账号密码的人就是 DBA 了，不然拿着它干嘛，除非是被迫的。

常规角度去看 DBA 角色这已经有太多人讨论过。包括这几年云计算发展产生的 Serverless 和 DBaaS 等新的云业务模式，确实是减少了一部分 DBA 岗位的需求。这里用“岗位”这个词，因为是影响到人。

讨论一个技术角色的未来，实际就是从事这个岗位的人有没有未来。

一、技术角色的存在是由什么来决定

如果单纯从技术角度看，任何技术角色都不能被认为是终身职业。信息技术的持续发展和自我革命会使得新角色不断出现替代原有的角色。

因此，关键先看看有没有强制性的角色存在性支撑，也就是合规要求。而合规要求中最不可忽视的就是安全合规（风险控制）。

在《网络安全法》的等级保护相关标准：GB/T 22239 之前的 2008 版中以职责分离的说明方式指出了数据库管理员这个角色，但在后来“等保 2.0”的 2019 版中取消了这个表述，笼统地称之为系统管理员。

虽然在等保中数据库管理员的重要性不如主责三员：安全主管、安全管理员、审计管理员，但职责分离是风险控制的典型预防措施，因此数据库管理员角色是具备单独配置的必要性的。所以在等保测评机构的测评细则中，大多依然是保留了对数据库管理员这个角色的职责分离考查。

随着《数据安全法》出台，数据安全管理相关人员的责任划分，基本上是不可能少了数据库管理员这个角色承担相关责任，否则在面对数据安全审计时，缺少数据库管理员的角色安排，可以被认定内控无效，职责分离不彻底。

二、存在性并不等于职业未来

既然这样生活无忧了……然而并不是，危机总是存在。我这里不谈风险控制，只谈如果要从技术角度安身立命，那么究竟一个人的数据库运维能力水平达到了什么程度才真正算是 DBA。

最简单的评价方法当然就是考个人能力认证了。只是 DBA 相关个人能力认证都是和厂商产品直接关联，这种情况还难以改变。没用过的产品不好考，用过的考了但个人发展或工作环境变化导致用不上就显得浪费。其它方向的能力认证确实不少，但必然超出了 DBA 角色范畴，这里就不讨论了。

所以考证最大作用还是在于向雇主证明个人能力的同时，顺便给雇主拿去为公司整体资质加上一笔。

而前面提到的 Serverless，DBaaS 这些据说导致 DBA 角色消亡的云端服务，实际并没有真正让 DBA 角色消亡，而只是让 DBA 角色进一步地聚焦在数据本身，免除了环境方面的干扰。因为对于无力承担职责分离人力成本的企业来说，本来就没有创造 DBA 的岗位。

只是在笔者这种什么都想学想了解的风格来说，这些“XX 即服务”会缩窄了自己能接触到的技术范围，导致失去了很多乐趣。

实际上，DBA 的岗位人员如果不兼开发，不兼架构师，关键是不接触业务，那就很难有工作亮点和独立成就。而有些企业还明确地把 DBA 归到运维，不允许干预设计和开发，隔离业务，那就只是个工具人。

而工具人要面临的危机，就是 AIGC。

三、DBA 和 AIGC

AIGC 对程序员的颠覆是显而易见的了。以后软件开发行业，需要从零开始编码的工作重归高智力人群且薪酬会更高，而一般开发人员就只剩下做测试，测试 AIGC 生成的代码，甚至连测试都没得做，两个 AI 互为开发和测试。

说远了。那么 AIGC 对 DBA 是否构成颠覆呢？

这也是必然的事情。不过情况和对程序员的颠覆有所不同。

AIGC 真正颠覆的是普通人。普通人大多数缺乏创造力，擅长的只是重复，所以容易被 AIGC 这种擅长融合复制的技术所取代。举一个我自己设计的例子作为说明，分别用了 ChatGPT-3.5 和文心一言：

1、问：

你需要进入非常熟悉 MYSQL 的 DBA 的角色，然后对以下两张以建表命令描述的、主子表关系的表判断其存在的不足，并给出修改意见。其中 test_master 是主表，test_sub 是子表。

CREATE TABLE `test_master` (  `master_id` int(10) unsigned NOT NULL AUTO_INCREMENT,  `content1` varchar(200) DEFAULT NULL,  `content2` varchar(20) DEFAULT NULL,  PRIMARY KEY (`master_id`)) ENGINE=InnoDB DEFAULT CHARSET=latin1 COLLATE=latin1_swedish_ci;
CREATE TABLE `test_sub` (  `sub_id` int(10) unsigned NOT NULL AUTO_INCREMENT,  `master_id` int(11) DEFAULT NULL,  `subcontent1` varchar(200) DEFAULT NULL,  PRIMARY KEY (`sub_id`)) ENGINE=InnoDB DEFAULT CHARSET=latin1 COLLATE=latin1_swedish_ci;

2、ChatGPT-3.5，答：

存在的不足：

1. 主表和子表之间的关系没有明确的外键约束。

2. 子表中的 master_id 字段没有设置索引。

修改意见：

1. 在 test_sub 表中添加外键约束，将 master_id 字段与 test_master 表的 master_id 字段关联起来，确保数据的完整性和一致性。

ALTER TABLE `test_sub` ADD CONSTRAINT `fk_master_id` FOREIGN KEY (`master_id`) REFERENCES `test_master` (`master_id`);

2. 在 test_sub 表的 master_id 字段上添加索引，以提高查询子表数据时的性能。

ALTER TABLE `test_sub` ADD INDEX `idx_master_id` (`master_id`);

修改后的表结构如下：

CREATE TABLE `test_master` (   `master_id` int(10) unsigned NOT NULL AUTO_INCREMENT,   `content1` varchar(200) DEFAULT NULL,   `content2` varchar(20) DEFAULT NULL,   PRIMARY KEY (`master_id`)) ENGINE=InnoDB DEFAULT CHARSET=latin1 COLLATE=latin1_swedish_ci;
CREATE TABLE `test_sub` (   `sub_id` int(10) unsigned NOT NULL AUTO_INCREMENT,   `master_id` int(11) DEFAULT NULL,   `subcontent1` varchar(200) DEFAULT NULL,   PRIMARY KEY (`sub_id`),   INDEX `idx_master_id` (`master_id`),   CONSTRAINT `fk_master_id` FOREIGN KEY (`master_id`) REFERENCES `test_master` (`master_id`)) ENGINE=InnoDB DEFAULT CHARSET=latin1 COLLATE=latin1_swedish_ci;  

3、文心一言，答：

这两张表看起来已经很好地定义了主子表关系。它们的设计在大多数情况下是足够的，但有一些可能的改进点。

主键设计：在 test_master 表中，主键 master_id 是自增的，这是常见的做法，因为它确保了主键的唯一性并且易于管理。然而，在 test_sub 表中，主键 sub_id 也是自增的，但并没有明显的必要。如果这个表中会有大量的数据，那么使用自增主键可能是有意义的，但如果数据量不大，可以考虑使用 UUID 或者其他类型的唯一标识符作为主键，这样可以避免因自增主键而带来的额外开销。

字段命名：建议将字段名改为更具描述性的名称。例如，content1 和 content2 可以改为更具描述性的名称，比如 master_content1 和 master_content2。

外键约束：为了更好地维护主子表关系，建议在 test_sub 表的 master_id 字段上添加外键约束，与 test_master 表的 master_id 字段关联。这将确保在 test_master 表中的记录在 test_sub 表中被引用，反之亦然。

下面是修改后的建表语句：

CREATE TABLE `test_master` (    `master_id` int(10) unsigned NOT NULL AUTO_INCREMENT,    `master_content1` varchar(200) DEFAULT NULL,    `master_content2` varchar(20) DEFAULT NULL,    PRIMARY KEY (`master_id`)  ) ENGINE=InnoDB DEFAULT CHARSET=latin1 COLLATE=latin1_swedish_ci;  
CREATE TABLE `test_sub` (    `sub_id` int(10) unsigned NOT NULL AUTO_INCREMENT,    `master_id` int(11) NOT NULL,    `subcontent1` varchar(200) DEFAULT NULL,    PRIMARY KEY (`sub_id`),    FOREIGN KEY (`master_id`) REFERENCES `test_master`(`master_id`)  ) ENGINE=InnoDB DEFAULT CHARSET=latin1 COLLATE=latin1_swedish_ci;

以上这些修改建议可以根据你的实际需求进行调整。

从以上问答记录可以清晰地观察到，AIGC 对于不需要发散和创造的问题上，完全具备替代一般的 DBA（包括开发人员）的能力。

所以 DBA 这个角色真正的职业未来在于个人创造力。

四、超越 AIGC 的创造力

要有超越 AIGC 的创造力，首要的不是技术水平，而是技术与业务结合的能力。

笔者在 N 年前，当时还没有什么大数据手段的时候，曾经为了一个业务统计用的查询，用了 2 天时间去打磨，反复优化，最终实现了查询统计耗时从两位数的分钟级下降到个位数的秒级。

在这个过程中，除了常规的查询优化手段之外（其实当时已经起不了多少优化作用），主要还是在于如何根据业务数据的实际情况，发现可以优化的关键特征，从而实现组合拳式的优化。

具体过程，是在经过分析发现常规的查询优化手段无效后，转而学习和研究业务运行情况，然后对统计输入的业务数据进行检查，发现地域信息、产品分类以及客户的某个属性等多个字段内容之间存在间接相关性。然后，通过试算确认相关性是可用于统计的关联性。再然后为了提高统计速度，通过拆分提取字段内容、单独建表和创建复合索引实现数据分层预处理，成为主数据上层的新主表，然后再主子表关联到主数据实现统计速度大幅度提升。

人的创造力在于从没有直接关联的事物中发现关联性（直觉），并掌握规律、利用规律。这是现在的 AIGC 尚不具备的能力，因此也不可能实现这个优化过程。

虽然 AI 也会不断进步，但离真正的人工智能出现还有相当长一段距离。而具体到个人的创造力是可以通过学习和训练而提升的，只要有主动性，就是 AI 对人的追赶关系。况且还要等到 AI 懂业务，那又是另外一种完全不同的情景了。

五、最后

不同能力水平的 DBA 需要找到自己的侧重点，在持续提升技能并获得外部确认的同时，熟悉业务把自己与业务捆绑起来是关键立足点。

另外就是巩固角色岗位具体工作内容和合规要求的结合度，从专业水平上做到无可替代。

进一步地，创造力是人和机器的区别。到最后就是 AI 如何取代人和人如何避免被 AI 取代。

只是，没有舒适区了，无论在哪个能力水平上。

个人博客：https://www.wavecn.com/content.php?id=382