数据库管理-第142期 DBA？DBA！（20240131）

作者：胖头鱼的鱼缸（尹海文）
Oracle ACE Associate: Database（Oracle与MySQL）
网思科技 DBA总监
10年数据库行业经验，现主要从事数据库服务工作
拥有OCM 11g/12c/19c、MySQL 8.0 OCP、Exadata、CDP等认证
墨天轮MVP、认证技术专家，ITPUB认证专家，OCM讲师
圈内拥有“总监”、“保安”、“国产数据库最大敌人”等称号，非著名社恐（社交恐怖分子）
公众号：胖头鱼的鱼缸；CSDN：胖头鱼的鱼缸（尹海文）；墨天轮：胖头鱼的鱼缸；ITPUB：yhw1809。
除授权转载并标明出处外，均为“非法”抄袭。

本来说这个月不写文章了，先是想了想一月写了13篇，13有点不吉利，但这不是重点，重点是今天晚上（1月31日）OSC又双叒搞了一个大招，需不需要DBA。哎，想来还是写写吧，作为个DBA，我肯定是站DBA的（至少在AI干掉所有人工作之前），但我又不是完全站某些人理解的那种片面的DBA。下面的文章内容应该会比较混乱，就一个章节。

正文

写代码的人，也就是开发人员，他们的能力真的是参差不齐，尤其是很low的开发，一条SQL就能把数据库干趴，我就没搞懂为啥这种语句在RDS上就不是问题了，RDS也是数据库也会跑挂，挂了云后台DBA很多时候也会介入。这种SQL不审核直接上线，业务挂了带来的损失大多数时候是比不上极速迭代带来的收益，毕竟口碑这种东西建起来难毁着挺快的。

说真的优化一条SQL，往往不能解决问题，源自于整个业务逻辑的问题，有时候其中某条SQL快了之后反而会引起业务流程一系列问题反而更慢。我从来不认为我优化了单条SQL就是能力多强，而是我在不断数据库管理过程中，逐渐熟悉业务后，与开发人员一起，带着他们从整个错误的逻辑层面去优化业务。

数据量不同，数据库和语句的运行状态是完全不一样的，所以不要拿那些小到不得了的数据库来对比大库，也不要说大库没有存在的必要，因为业务场景不同，也不要拿全点查的业务来对比天生偏向HTAP的业务。

业务场景决定了你会产生何种类型的数据，这些数据应该怎么存放，存放方式又决定了数据使用方式，别总说DBA滥用关系型数据库，我也是略懂各类NoSQL数据库的，也会根据业务情况建议使用不同的数据库，甚至建议仅维持一些数据的状态（不落库）。再说了Oracle和不少关系型数据库也在走向融合的道路，简化数据的使用方式。

由于我服务客户的原因，全都是自建IDC，不能上公有云，顶多算是私有云（我这管理数据库全是物理机）。我也能做到足够的高可用性，也能做到业务出现问题（影响数据库性能时）先敌发现、先敌反馈、先敌处理（绝对的细粒度监控告警，甚至很多云上都实现不了）。

总结

我认为，业务场景决定了数据组织形态，数据组织形态又决定了该如何使用数据，这中间如何实现高效转化，才是DBA最大的价值。
老规矩，不知道写了些啥。