数据库“问题”制造者五花八门，终究是DBA扛下了所有 - 更多 - dbaplus社群：围绕Data、...

carol11 2023-01-07 09:59:00

从事DB 的工作者在工作中，大多都会遇到一些制造数据库的“问题”的开发者，实际上看问题的从多方面来去看，问题的的制造在会加重DBA 的工作，并且添加更多数据库在运行中产生问题的几率与制造数据库运行不稳定的因素，从另一个面来看，如果没有这些“可爱”的问题制造者，DBA 的工作是枯燥和乏味的，没有成就感的。今天就来捋一捋DB 在工作中，会遇到一些有意思的开发者。

从事软件开发的开发者分为多种类型，有自身架构师类型的，也有开发小白，或我们俗称的码农，对比多年前，最近几年开发者对数据库可以选择的种类越来越多，同时构建代码可以用到的工具也越来越多，这就产生了矛盾，一部分是开发者对数据库产品不熟悉不了解，尤其是新品，另外一部分这些开发软件模块让开发者更像是一个流水线上的组装模块的工人，微服务和敏捷开发让开发者更注重在业务的理解和代码的拼凑上。这就形成了一个矛盾，数据库的可选择的范围越来越多，但能弄清这些数据库使用的方式和注意事项，以及技巧的开发者并未增多，从中也就产生了一种新的DBA 可以参与工作的层面，或者我们可以说一个 database 买手的工作。

这里先不谈，更多的数据库品类增多给DBA 产生的新的机遇，我们先来认识一些DB在工作中常见的“一小撮” 开发者，或者说数据库“问题”的制造者，并且我们来给他们归归类。

Developer种子选手1：胡选八选和一根筋

选错对象，嫁错郎， 此种开发者不知道是怎么回事，两种极端，要不一根筋，这辈子就只用一种数据库，什么场景都要使用这一种数据库，存储任何对象用传统数据库，存储日志，用传统数据库，存储图片还用传统数据库，对传统数据库是真爱。不管选择的传统数据库是否在他所使用的这个层面是否适合，或能承受这样的业务数据或业务类型。

而另一种也很有意思，花心大萝卜，这类开发人员希望在一个项目用几种“古怪”数据库，通过使用来尝试各种数据库产品，体现自己的博学，但在使用中并未理解每种数据库的长处和短处，用NOSQL数据库处理多表关系型分析，用传统数据库来存储日志，甚至大型JSON 文件，精确的将各种数据库的弱点准确用到项目中，完美的采坑。

Developer种子选手2：串行思维患者

这类开发者的思维模式，尤其在SQL方面给 DB 带来了极大的不适感，这类开发者在撰写SQL 的时候，思维模式是串行的并且和 “抻面” 一样绵延不绝。

例如在一个SQL中，包含了数据库提供的各种复杂写法的集合，子查询，子查询套子查询，子查询作为 JOIN 表存在， 子查询作为 GROUP BY  HAVING 的值存在， SELECT  字段上进行判断 CASE WHEN  ，比大小，字段用一个表的查询的值来表达，只有你想不到的，没有他做不到的，这类程序员，如果将这样的SQL 撰写方式，应用到代码中，那么大多得到的是 唾沫星子。

Developers种子选手3：无设计，比萨斜塔建设者

这类开发者的脑洞没有，但是他们有强大的 “垒” 的技巧，一个表已经承载了复杂业务功能并且可能一个表已经有了20多列，但只要接到新的需求，只要可以和这个表 “凑” 在一起的，他一定会凑到这张表里面，一个表100多列在他看来，也不是不可以。最终导致数据库的 热点表，死锁，BLOCKED 等等问题，UPDATE 也经常失败。这样的开发者只能送他一句， 你真是一个好 “砖”家，潜移默化的将整个项目拖入“死水”。

Developers种子选手4：数据库=数据仓库与过分性能控

这类开发者看上去是很认真的，一个表设计，一个语句的斟酌，索引是一个一个的加，生怕那个查询语句没有索引，耽误了查询的性能。可在整体表设计中从来不考虑，表的大小与数据库类型所承载的表大小的限制，只要磁盘不告警，优化手段来一遍，就是数据不归档，问就是，我优化了，数据不能清理。

呵呵，我到想问你一句，你既然知道数据不能清理，不能动，为什么之前不分表操作，挑战某种数据库的单表存储极限，是你毕生的夙愿。、

另外针对过分性能控最大的感受就是，抓小，放大，多了不说自己体会。

数据库不是数据仓库，

数据仓库不是数据库，

数据库擅长OLTP 中小型事务处理，

数据仓库精通OLAP大型分析处理，

你非把数据库当数据仓库使用，

数据库偏不让你把他当仓库使用，

你抬手打了数据库一嘴巴，数据库滴滴答答吹喇叭！

Developers种子选手5：服务器硬件批发商

这类开发者，一定是服务器厂商最喜爱的程序员之首，这样的程序员属于集合上面那些程序员的特点于一身，同时还能自创一些独门武功， 如

字段只要大不要小， 是个文字字段不给200以上都对不起数据库，口头上说，这样避免后期扩展字段。语句撰写是怎么不符合数据库的原理怎么写，条件在左做计算的， 两个表进行JOIN 关键字段类型不一的，一个数据库存上万张表。

一个数据库不给他准备256核心CPU  2T 内存  SSD 光纤阵列都HOLD不住他的设计，硬件对他们来说，一直都是不够用，人送外号，硬件杀手。（说这些人是程序员就范围小了，在架构上的错误才是让硬件永远不够用的 “根”）

针对这些开发者，DB 该怎么办，才是我们需要分析和思考的。

对于这样的开发同学，DB 同学必须具有以下方式，杜绝在你所负责的项目中让他们来选择数据库，他们可以建议，但DB 应该具有抉择和方案的建议权（最好有决策权）。

这就要求在这样场景下 DB 同学具有以下的一些能力：

• 针对多种数据库本身的优势和缺点有明确的认知，并且有一些证据证明你所阐述的问题的论证。

• 针对开发业务场景的理解，并通过分析场景来估算大致数据库的适应场景与解决方案

• 针对选择的数据库的一些特性和功能，有明确的认知，并可以通过这些功能来确认可以解决部分开发应用场景的问题，并进行归类。

最终，持续修炼自己，让自己在多种知识方面，尽量少的有盲区，多读书多看报，多和业界大佬倾听，多尝试，多测试 。

作者丨carol11 来源丨公众号：AustinDatabases（ID：AustinDatabases） dbaplus社群欢迎广大技术人员投稿，投稿邮箱：[email protected]