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

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

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

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

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

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

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

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

数据库不是数据仓库，

数据仓库不是数据库，

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

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

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

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

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

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

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

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

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

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

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

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