千万别以为这是我的YY，你不信你私底下去探听一下，大部分开发对于DBA的看法基本就如此了。架构对于DBA的看法，基本就是没有看法，DBA 是什么，空气吧……

基本上什么背锅侠、受气包、倒霉蛋，和一些DBA很沾边，不信你身边就有这样的小朋友。

反观，什么是架构师？耀眼的、璀璨的、高大上的、应用架构、硬件架构、数据架构、基础架构等等……为什么在常人的角度，架构就高人一等。实际上架构是怎么产生的，主要的因素之一就是——大。

因为一个项目大，所以需要一个基础架构、一个应用架构、一个数据架构，这些架构的意义在于，承担分配任务和合理化组合配置的工作。

大白话就是，架构是大脑，他的脑子里面有一个清晰的整体的三维的对他负责的部分的整体认知，如同木桶，他深知那个板子重要，那个板子可以放弃，而你就是板子。

那么架构产生的5大要素：1、创造性的工作；2、需要由人来进行的工作；3、工作的涉及的领域广；4、工作产生的结果很重要；5、工作复杂度高，参与的人或工作需要进行合理的分配和调度以及组合。

举例盖房子，总工程师他手下有各种的工种：成本工程师、水电工程师、结构工程师、外延工程师等等，那么总工程师可能在每个专业上都不如这些工程师在这个领域专业，但是他的看问题的角度是综合的，他具备这些工程师基本的知识，并且能融汇贯通中，加以利用这些人，这些专业知识，让他们发挥到最大。

回到数据库，数据库为什么在有些人眼里低级，因为创造性。一个工作如果只是循规蹈矩，那么必然是得不到尊重的，而发现问题，解决问题是具有创造性的。

回到题目，为什么DBA要会架构，因为你会了，就没有人能欺负你了，比如软件工程师，在开发中产生了一个BUG ，而如果你不懂产生问题的基本原因那么.....你就得被忽悠。

举例：一个数据库系统中，存在OLTP + OLAP 混合应用，但这个数据库本身就只能处理OLTP，产生了数据库系统性能低的问题，首先不懂的人，要找的就是DBA：

……等等这些问题，如果你仅仅从数据库的角度看问题，就如同：你就是一只鸡，人家拿笸箩把你罩起来，你横竖都是die。

怎么办？提高认知的维度，把视野不在锁定到数据库本身，而是基于数据库的半径，开始往上 、往下、往左、往右的扩展你的知识层次。

当他举例当他人提出，你是怎么优化SQL ，如果你是一只鸡，那么你一定会责怪自己，我怎么就没有优化好一个SQL，实际上你优化了这个SQL也不见得会解决问题，因为还有别的SQL，同时还有因为软件架构导致的，语句无法优化的情况（诸如某些软件的结构，就已经限定了一个框架，让你的SQL不能进行手动的改写，或大概率的不能进行改写）。

此时如果你是仅仅就思考SQL的问题，那么就应该变成一只烧鸡。

你应该想的是：抛弃SQL撰写的维度，提升维度去想，明明这个应用系统，并发高，同时数据量大，但是他就用了一个MYSQL来解决问题，那么问题的终结是，他用错了数据库，错不在你，但如果你只研究MYSQL，最终你研究的在透，你无非就是在拖延，你死的时间，也就是数据增长与数据库查询和硬件不升级之间的矛盾问题。

此时你不过是在等死，正确的思维模式是：

1、这个项目的数据量是多少？单天多少？有没有可能有突发数据的写入？有没有可能有大量的跑批的工作？有没有因为业务的原因？数据库表会经常被改动添加结构字段等等。

你问了这些问题，那么你必然不会选择一个，单机的MYSQL 5.7作为你的基础数据库，同时如果架构师给你要求说，我们的项目就用 MYSQL 5.7作为基础数据库。

此时你基于更大的思维模式，你必然要DISS他，往死里DISS， 用他不擅长或一知半解的MYSQL 5.7的知识，逼得让他换一个数据库选型，或让他上吊。就算是不行，此时你在最初已经知道这个项目的结果，保留好证据你说过什么，提过什么，最终项目出现问题，再有一些，架构，开发来让你变成“烧鸡”，那么你就连他一起烧了。

2、如何连架构和开发一起给他烧了，你必须在数据库专业的知识上，打他们一个措手不及，你必须是专业的，对你所要使用的数据库整体或细节，以及周边都有一定的认知，俗称你知道坑在哪里。

那么你知道坑在哪里，一你不会跳，二如果他让你跳，你也可以有手段让他先出丑。用你的专业知识，让他显得非常的无知，记住是非常的无知。

那么结果很简单，你就即将不再是那个，被忽视的“数据库操作工”，而是一个可以出谋划策，数据库工程师，此时你就晋级了。

当然这还不够，你如果想做到和架构师平起平坐，那还早着呢，首先你掌握的数据库类型一定要广，至少每个类型的数据库你至少的掌握一个，不能人家提起MOGNODB、REDIS，你和白痴一样，什么是跳表？什么是TTL 索引？什么是链表？HASHTABLE的结构？MONGODB的优点是什么？REDIS 5后的多线程是什么意思？那里是多线程，不是单线程吗？等等这些你要心里有数，在他们使用任何的产品的时候，你都能明细，他在这个项目中用的数据库是否会产生风险？是否合适？多长时间后可能要出问题？你怎么尽早的规避，产生新的方案来予以应对。

不过你也不用太担心，架构师和开发，在数据库方面没什么刷子，大多都是MYSQL或ORACLE的铁杆粉丝，其他的基本不会深入，剩下的就是你和他们比拼数据库广度和深度的部分（当然不是安装数据库这样的问题，而是数据库的特点、缺点，以及失败案例）。

然后你再开始找一些，服务架构的书籍，看看、学学，了解一下，就当看小儿书了，此时在有人想拿你当一个生瓜蛋子随意的欺负，那就不大可能了。只要你思考的维度比他高，那么他一定是手下败将，人生很短，不服就干。