数据库“问题”制造者五花八门，终究是DBA扛下了所有
d
dbaplus社群约 5 分钟
dbaplus社群约 5 分钟
从事DB 的工作者在工作中，大多都会遇到一些制造数据库的“问题”的开发者，实际上看问题的从多方面来去看，问题的的制造在会加重DBA 的工作，并且添加更多数据库在运行中产生问题的几率与制造数据库运行不稳定的因素，从另一个面来看，如果没有这些“可爱”的问题制造者，DBA 的工作是枯燥和乏味的，没有成就感的。今天就来捋一捋DB 在工作中，会遇到一些有意思的开发者。
从事软件开发的开发者分为多种类型，有自身架构师类型的，也有开发小白，或我们俗称的码农，对比多年前，最近几年开发者对数据库可以选择的种类越来越多，同时构建代码可以用到的工具也越来越多，这就产生了矛盾，一部分是开发者对数据库产品不熟悉不了解，尤其是新品，另外一部分这些开发软件模块让开发者更像是一个流水线上的组装模块的工人，微服务和敏捷开发让开发者更注重在业务的理解和代码的拼凑上。这就形成了一个矛盾，数据库的可选择的范围越来越多，但能弄清这些数据库使用的方式和注意事项，以及技巧的开发者并未增多，从中也就产生了一种新的DBA 可以参与工作的层面，或者我们可以说一个 database 买手 的工作。
这里先不谈，更多的数据库品类增多给DBA 产生的新的机遇，我们先来认识一些DB在工作中常见的“一小撮” 开发者，或者说数据库“问题”的制造者，并且我们来给他们归归类。
而另一种也很有意思，花心大萝卜，这类开发人员希望在一个项目用几种“古怪”数据库，通过使用来尝试各种数据库产品，体现自己的博学，但在使用中并未理解每种数据库的长处和短处，用NOSQL数据库处理多表关系型分析，用传统数据库来存储日志，甚至大型JSON 文件，精确的将各种数据库的弱点准确用到项目中，完美的采坑。
例如在一个SQL中，包含了数据库提供的各种复杂写法的集合，子查询，子查询套子查询，子查询作为 JOIN 表存在， 子查询作为 GROUP BY HAVING 的值存在， SELECT 字段上进行判断 CASE WHEN ，比大小，字段用一个表的查询的值来表达，只有你想不到的，没有他做不到的，这类程序员，如果将这样的SQL 撰写方式，应用到代码中，那么大多得到的是 唾沫星子。
呵呵，我到想问你一句，你既然知道数据不能清理，不能动，为什么之前不分表操作，挑战某种数据库的单表存储极限，是你毕生的夙愿。、
另外针对过分性能控最大的感受就是，抓小，放大，多了不说自己体会。
数据库不是数据仓库， 数据仓库不是数据库， 数据库擅长OLTP 中小型事务处理， 数据仓库精通OLAP大型分析处理， 你非把数据库当数据仓库使用， 数据库偏不让你把他当仓库使用， 你抬手打了数据库一嘴巴，数据库滴滴答答吹喇叭！
字段只要大不要小， 是个文字字段不给200以上都对不起数据库，口头上说，这样避免后期扩展字段。语句撰写是怎么不符合数据库的原理怎么写，条件在左做计算的， 两个表进行JOIN 关键字段类型不一的，一个数据库存上万张表。
一个数据库不给他准备256核心CPU 2T 内存 SSD 光纤阵列都HOLD不住他的设计，硬件对他们来说，一直都是不够用，人送外号，硬件杀手。（说这些人是程序员就范围小了，在架构上的错误才是让硬件永远不够用的 “根”）
针对这些开发者，DB 该怎么办，才是我们需要分析和思考的。
对于这样的开发同学，DB 同学必须具有以下方式，杜绝在你所负责的项目中让他们来选择数据库，他们可以建议，但DB 应该具有抉择和方案的建议权（最好有决策权）。
这就要求在这样场景下 DB 同学具有以下的一些能力：
- 针对多种数据库本身的优势和缺点有明确的认知，并且有一些证据证明你所阐述的问题的论证。
-
针对开发业务场景的理解，并通过分析场景来估算大致数据库的适应场景与解决方案
-
针对选择的数据库的一些特性和功能，有明确的认知，并可以通过这些功能来确认可以解决部分开发应用场景的问题，并进行归类。
最终，持续修炼自己，让自己在多种知识方面，尽量少的有盲区，多读书多看报，多和业界大佬倾听，多尝试，多测试 。