上上周作者约战，很久没等到，我以为过去了，还是来了。那我们就回应一下，我仅代表我和和我类似感受的同仁进行回应。
首先对其： DBA的价值空间的这个段落进行驳斥。他提到的：“但是可惜的是，过去十几年来，行业趋势是反的：DBA能达到的上限在下降，而没有DBA的下限显著地提高了。 ”实际情况恰恰相反。我认识70后的开发，开发入职考算法，写SQL看执行计划。但是90后的连索引是什么都未必知道。我们这里不知道是不是接触的人不同。我经历了几个行业，国企私企都做过。发现都是这样。外国开发水平如何我不知道，我没接触过。其次我的环境没有在公有云上。我个人认为私有云不是云（没有云的属性）。但是我帮别人他们租用处理过阿里云和腾讯云中使用过程中遇到的问题。我是针对以上的经历发言。我接触过一些开发，问他这个怎么来的到哪里去？他说不知道，我只管调用接口。我问知不知道全表查询？不知道。我问知道这个锁是怎么回事，和哪些有关？不知道。 以上不是所有，但是是国内比较普遍的。10年前我遇到的问题，10年后的今天依然遇到。不知道这些基础问题的人还是很多的。对于堆表的数据库，很多人至今还以为删除数据表中的数据，再全表查询能提高效率。对于模糊查询，时至今日还有人觉得要先%ABC or 一下ABC%组合起来，这也有。SQL只管逻辑对了，性能好不好不管。把机器拉满。当然公有云可以弹性扩展存储和计算，但是这个钱就花了。实际上写好点，很多满负荷的数据库，最后都变成空载的数据库。这种我处理过上百个数据库实例了。如果有公司愿意当冤大头，那我就不说什么了。其次是在非公有云环境中这种场景数据库基本就不能正常工作。而更重要的是我看到很多连逻辑都写错的。这种太多了，每周我都能见到。（各种群）
其次对其： 下限提升：免DBA得到更快的DB交付速度 这个段落部分进行驳斥。他提到的部分是对，就是云简化交付。这里的云是说公有云，这也就是云的属性，解决了快速获得的问题。但是重要的来了，我也一再强调，很多公司是上不了 公有 云的。而且我觉得在中国是不上公有云的比上 公有 云的多的多（国企、央企、事业单位、*还有各种各样等等太多了）。 （私有云不是云，解决不了这里说的快速获得的问题）所以还有这个快速交付的仅仅占一小部分。在国外不知道如何，在中国这个占比还是不大。
下面一个段落： 下限提升：远离DBA，远离分库分表。这是文章中对开发说的。我赞同开发提升，也赞同不要分库分表。但是后面就开始乱说了。“DBA们只懂单机关系型数据库 ”。这是20年前的没有其他数据库的时候了。请不要停留在过去。以我为例：使用、维护和学习过Oracle/MySQL/SQLSERVER/DB2/PostgreSQL/Redis/Cassandra/mongodb/Hbase/Hive/elasticsearch/neo4j/influxdb/Tdengine/ClickHouse/Greenplum/timesten/memcache/TiDB/OceanBase/达梦/TDSQL/RabbitMQ/Kafka/OGG。我相信在国内不止我一个人这样。所以这个只懂关系数据库的论点站不住脚。虽然我都不是很精通，但是我应该有发言权。RDBMS在很多领域为主，NoSQL配合。毕竟我们很少见到在线交易用NoSQL支持吧。然后只要是懂数据库的DBA都讨厌分库分表，我倒是认为很多场景都是开发没写好，然后采用分库分表来缓解的。我本人最不喜欢分库分表。
再下一个段落： 上限下降：不断出现的删库跑路。更加是不负责任的言论了。国内数据库实例有多少？一千万都不止吧。极个别违背职业道德有删除的，不能说明整体。你请看看删库的多，还是SQL写的笛卡尔积多？难道SQL写成这样就不要开发了吗？这和某地出现一个坏人，说这个地域全是坏人有什么区别？
最后一段：有四个公司说没有设置DBA岗位。请问1哪4家？请问2说明除了这4家都要。请问3，您知道什么是DBA吗？database administrator？不。他还包括了database analyst 和database architect 。云只是做了administrator的一部分。做了标准化安装、高可用和备份等基础操作。但是优化呢？会给你找出TOP-SQL但是不会告诉你如何改？
举例1：一个16个表的关联，一看就不合理。分析过后，发现有些字段不是必须，既然不是必须那么这个表可以不用关联。那么第一步我们就可以减少4张表关联。请问哪个云厂商去这样给建议的？如果有告知一下名字。不是说云都不看用户数据的吗？这是database administrator的范畴。
举例2：有一次我看到了这样一句消耗高的，select * from t where a=xx or b=yy 看到这里可能一般人要说，加索引了。那么如果就是加索引这种技术含量就不太高了。2018年Oracle就发布了自动化索引的版本，那么说明这种在更早版本就筹划，甚至更早时间就设计了。云如果解决了这个是应该的，因为这是他应该做的。我这里要说的是，我就好奇进去看了一下b列的数据。发现B列3年以来都是空的。我就找开发说这个SQL不合理，然后拿出分析数据。开发当时就惊呆了，然后开发去问业务为什么会这样。业务说，这个业务场景早就不用了。该功能也不会用了。请问哪个云厂商去这样给建议的？如果有告知一下名字。不是说云都不看用户数据的吗？ 说到这里，可以看出来这是database
analyst。通过分析发现问题。
举例3： 又有一次我经历一家公司为了解决登录问题，涉及到的数据库有Oracle Redis mongo Memcache Cassandra。这些是串行的一个环节有问题，登录就出问题。这些是我调研的结果，了解到只需要每秒处理1000个登录请求就行。那么我就把mongo Memcache Cassandra
这些全去掉了，其实直接访问Oracle就行，最后还是给他留一个Redis。请问哪个云厂商去这样给建议的？如果有告知一下名字。云厂商巴不得你多花钱，我从来是精简架构为宗旨，少花钱才是价值。说到这里，可以看出来这是database architect。
例子太多，不占用读者时间。总是以上例子没有一个是公有云能帮我的。更何况广大不用公有云的公司。那么以上问题谁来解决呢？很多场景从需求就要介入、还是设计包括逻辑设计、最后是实现都是数据库的各种DBA去完成。做的过来和做不过来是另外一回事，做不过来可以通过招DBA来完成。