评论：关于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。
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的创造力，首要的不是技术水平，而是技术与业务结合的能力。
笔者在N年前，当时还没有什么大数据手段的时候，曾经为了一个业务统计用的查询，用了2天时间去打磨，反复优化，最终实现了查询统计耗时从两位数的分钟级下降到个位数的秒级。
在这个过程中，除了常规的查询优化手段之外（其实当时已经起不了多少优化作用），主要还是在于如何根据业务数据的实际情况，发现可以优化的关键特征，从而实现组合拳式的优化。
具体过程，是在经过分析发现常规的查询优化手段无效后，转而学习和研究业务运行情况，然后对统计输入的业务数据进行检查，发现地域信息、产品分类以及客户的某个属性等多个字段内容之间存在间接相关性。然后，通过试算确认相关性是可用于统计的关联性。再然后为了提高统计速度，通过拆分提取字段内容、单独建表和创建复合索引实现数据分层预处理，成为主数据上层的新主表，然后再主子表关联到主数据实现统计速度大幅度提升。
人的创造力在于从没有直接关联的事物中发现关联性（直觉），并掌握规律、利用规律。这是现在的AIGC尚不具备的能力，因此也不可能实现这个优化过程。
虽然AI也会不断进步，但离真正的人工智能出现还有相当长一段距离。而具体到个人的创造力是可以通过学习和训练而提升的，只要有主动性，就是AI对人的追赶关系。况且还要等到AI懂业务，那又是另外一种完全不同的情景了。
不同能力水平的DBA需要找到自己的侧重点，在持续提升技能并获得外部确认的同时，熟悉业务把自己与业务捆绑起来是关键立足点。
另外就是巩固角色岗位具体工作内容和合规要求的结合度，从专业水平上做到无可替代。
进一步地，创造力是人和机器的区别。到最后就是AI如何取代人和人如何避免被AI取代。
只是，没有舒适区了，无论在哪个能力水平上。
