我是一名工作在北京的DBA实习生，3年前在机场看到硕大的广告牌上写着“1号店采用Oracle Exadata运行速度加快7倍”，这是数据库给我留下的第一印象，之后它给我的生活带来的影响更是愈渐深远。在银行的实习中，我感受到如今行业间的竞争力重点在于运行速度、数据分析、客户忠诚度等，这使得企业不惜花重金去搭建与维护自己的数据库。DBA成为信息时代的幕后英雄，用最精准的分析，科学的办法，每天和最聪明的人在一起，做着改变世界的工作。

我是一个数据库开发的实习生，从开始接触数据库到如今的实习都对这个行业充满着浓厚的兴趣，我们通过操作和管理数据库把一些信息数据集合起来处理成我们需求的数据，大大减少人力物力的消耗，这个过程本身就很美妙。在当下大数据的时代背景下，数据库的开发管理更加需要我们挖掘一些新的技术，以适应科学技术发展的步伐，我相信未来这个行业肩负着更多的责任，对此我更愿意去陪伴它一起成长。

进入这个公司已经有快两个月了，从搭建单实例数据库，搭建DG，我算是明白了，我在这两个月的时间里，学到了很多东西，自己琢磨到的东西也很多。现在的我就是想好好学习，慢慢来，我是急性子，同时我也明白学Oracle数据库不能急，得慢慢来，书中自有黄金屋么，多读，不要贪心就好。我现在是这样想的，我也这样做了。多少同学说羡慕我干了技术岗，可是他们不知道我是真的很心痛，很捉急，很无奈。我告知他们的就是一句话：养精蓄锐，这也是告诫我自己的。

我是一个有着1年经验的MySQL DBA萌新。在我看来DBA存在的价值越来越体现于Performance。数据库安装、架构搭建及日常维护占据了DBA 70%的工作精力，而目前云服务正在逐步代替这70%的工作量。如何提高剩下30%的优化、处理能力显得尤为重要。在我看来工作过程中对数据、日志的敏锐定位和性能优化会让一个DBA在这个云时代站稳脚跟。

我是个刚工作半年的Oracle DBA，因为自己很喜欢Oracle这一方面的知识，可以带给你很多乐趣。但是同时也很彷徨，因为不知道什么工作适合自己，什么工作才能让自己得到提升。

在这个着急的时代，着急的自己，有时候想找到一条出路。最后希望自己在Oracle这条路上越走越好。

我是一名电商行业IT团队的HRBP，DBA团队可以说是公司业务团队的核心，App崩了可以再上线，服务器挂了可以再装系统甚至再次购买，但是极少有公司甚至行业能承受住数据库丢失的打击，我眼中的DBA不单单是作为机房、数据库的管控、调用，更多的是为数据的管理与优化提供服务的人，他们能做到稳定服务器，保证配置最优化，利用数据资源进行程序优化，最后就是日常维护与性能数据收集。

DBA，在我眼中一个只会说no的职业。建表：不行，不规范。加字段：不行，英语拼写语义不明。链表查询：不行，去优化SQL。存储图片：不行，去存硬盘。等等等，数不胜数的no。有时候在想，DBA是上帝派来消灭我们的吗？时光如梭，随着我们项目的逐渐扩展，我去，又有bug，怎么数据库就不宕呢。如今不得不佩服敌人的狡诈与严格。

作为一个开发人员，和DBA打交道还是挺频繁的，如果直接说我眼中的DBA有点抽象，还是先来列举下开发通常什么时候会找DBA吧。

最频繁的情况，在开发过程中遇到比较复杂或执行时间较长的SQL第一反应就是找DBA优化，那自然是相当于购买了保险嘛；有些程序运行一段时间后执行效率变差了或者干脆罢工了，会找DBA检查是否死锁了，数据库连接不够用了等等。

还有一些低级的应该比较不受DBA欢迎的问题，比如锁表了需要解锁，误删数据了需要恢复数据（最好不要发生，否则真的很麻烦）等等。

如果足够幸运能遇到一个懂开发的DBA，那么我在做一些涉及到大数据量存储或更新的程序设计时，会先找DBA咨询一下，程序中如此大数据量的频繁读写是否会给数据库造成很大的压力，看如何做可以使性能更好等等。

总结一下就是数据库管理和优化的工作都会涉及到DBA。

如果和DBA配合得好，那么DBA对于开发人员来说就是了不起的幕后英雄，反之，就会由于某些界限不是很明确的问题，比如性能问题，而陷入双方都尴尬的境地。

我是一个BI方向的项目经理，有7年的财险数据统计方面的工作经验，接触的DBA基本是甲方信息技术部的员工，经常找他们解决的问题如下：服务器上安装数据库软件、权限控制、表空间增加、变更用户密码、数据库宕机解决等。有时间他们也找我们，给出最耗资源的前10大SQL，让优化。

感觉DBA们时闲时忙，闲的时候多，不过忙的时候一般都是夜深人静的时候搞升级，也有配合数据库厂商的升级。

感觉DBA们各个肩负重任，一个公司数据的安全需要他们负责，所以他们肯定7*24小时不能关机，随时待命。

感觉DBA们都挺不容易的，当然薪资高也是正常的，一份付出一份收获。

我是一个开发人员，要说我眼中的DBA，就从我平时工作中和DBA打交道的地方开始吧，比如新建表结构，增加索引，查询线上数据等等，作为开发人员都要求提供准确的ip，用户和SQL语句，举个例子，有一次我们批量修复一批数据，我们把SQL都拼好了，但是没有写后面的分号，DBA同学就给返回来了，当时我自己还有点小情绪，不过被DBA同学机智的看穿了，和我解释了一下，说他们每天这种查询和更新的工作量很大，如果不标准，工作很难进行。我想了下确实如此，以后我给DBA的每个SQL都是可以直接被执行的。因为很多时候不是DBA同学针对谁，是他们为了确保数据的准确性，必须要你提供这些数据，因为差一点线上都会出错的。拒绝你的DBA才是负责的DBA。

说了工作上和DBA的日常交互，再说下开发人员比较关注的点：数据备份，线上数据同步到线下（分为按天同步或者实时同步），SQL优化，连接数的合理分配等。我们之前有个内部项目MySQL不定期的出现insert延时，之前我们的解决办法就是重启MySQL，近期又出现就找了我们的DBA同学帮忙查看，最后查出来是因为备份的策略，帮我们搞了优化。
 

最后希望我们同是搞技术但不同岗位的童鞋能够多多交流，也希望每个开发人员都能遇到一个给力的DBA同学。

我从事Java开发8年，由于从事电信相关软件的研发，在工作中常常遇到性能调优问题，而数据库查询语句相关的调优问题又占了绝大多数。

由于数据库查询语句的复杂性，遇到此类问题常常咨询DBA同事，与DBA的接触就多了起来。

在我印象中DBA们大多技术能力强，都是特别喜爱钻研技术的，下班后还常常端坐在电脑前调试来调试去。

他们往往不固守在自己的技术领域，而是掌握多种技能。常常站在技术的前沿，在我刚刚看到一个新鲜技术的时候，找他们去交谈的时候常常会发现他们已经用这种技术写了demo了。

接触多了还发现DBA们大多做事认真，很多事交给他们去做会很放心。

最后说一句，也许是DBA行业的特点吧，我接触的DBA们要么早早花白了头发、要么就没了头发...

我从事Java开发工作已经有10年了，目前是一名架构师，其实我从刚参加工作的时候就非常崇拜DBA，当时是在电信企业工作感觉DBA做的工作比Java高端多了，只不过后来由于机缘没有转过来。

我目前所从事的行业是互联网支付方面，数据库使用的是DB2，那么在互联网行业的DBA和传统行业的DBA又稍有不同，以往讲的都是DevOps，开发既运维，我想未来在互联网行业的趋势也有可能增加一个开发DBA，于是在我的眼里DBA的理解是这样的：

第一、DBA要有过硬的数据库知识，包括管理、设计、开发等等。

第二、DBA要能够协助程序员提供底限防控。

第三、DBA要能够实时监控应用表并能够提供合理建议。

第四、DBA要能够具有应急能力。

第五、具有良好的沟通能力。

总之，DBA是安全、风险的最后一道屏障，作为一名程序员应加强与DBA沟通和协作。

早年从事软件开发工作，后因个人兴趣转做DBA，现从事与数据库相关的架构类工作。在我看来，DBA职业正在悄然发生几个变化：

1.随着数据库使用多年，对数据库运维层面更加深入。记得早年论坛上，咨询帖子最多的就是如何安装数据库等，现在已很少看到。
2.运维DBA与开发DBA重心在发生变化。随着数据库自动化运维不断提升、甚至云数据库的推广使用，对运维DBA的技能需求逐步减少，开发类的逐步增多。
3.DevOps技能逐步成为DBA必备的技能之一。纯管理型DBA逐步减少，通过开发脚本、工具乃至平台解决数据库问题，成为DBA的根本要求。
4.未来对数据治理等领域要求增多，DBA不再局限于"库"的领域，可上升为整个数据层面。从DBA（Database Administator）成长为DA（Data Architect）

我是一个工作8年的测试人员，我眼中的DBA，工作内容是对数据库进行设计，优化SQL语句，对数据库升级，迁移，备份等。DBA同学的部分特质，跟测试人员的特质较相似，如：胆大，心细，知识面广，技术能力强等。然而，在我的认知中，DBA还是一个技术过硬的性能测试工程师，目前经历的工作中，唯一跟DBA打交道的工作就是做性能测试的时候，通常我们对业务场景进行性能测试时，会要求DBA开通服务器指标的监控权限，或要求DBA对服务器指标进行监控。在我们提交测试报告后，DBA会根据测试结果对数据库进行性能调优，实现业务场景的性能优化，值得我们学习。

我是一个来自湖南移动的技术管理者，2006年接触Oracle数据库，2008年通过Oracle 9I 的OCP考试，同时兼职公司的Oracle数据库维护工作。从最简单的表空间维护和日常故障处理，学会分析故障，发现永远有填不完的坑。于是参与数据库的架构设计，从单节点改造成RAC，几年后由把双节点RAC改造成Extend RAC，建成读写双活中心。随着公司使用的数据库类型越来越多，从Oracle、DB2到Oracle、DB2、Greenplum、MySQL，MongoDB、Hadoop并存，发现自己越来越难集中精力去专研技术细节，逐渐成为一个啥也不精，什么都略知一二的“砖家”。

我是一名有多年技术工作经验的工作者。我认为称职的DBA要对数据库基本原理有透彻的理解，并熟练掌握相关数据库产品的工作原理和常用功能；对用户业务有一定了解，能与用户进行有效的沟通，快速理解用户所遇到的问题；具有一定的编程能力，能快速重现用户的问题，能与开发人员进行良好的合作；对数据库所处的软硬件环境具备一定的知识；了解、掌握运维自动化、云服务等新知识。

回头看十几年的DBA生涯，整个IT架构和环境越来越复杂，对DBA的要求越来越高。对于大型软件的开发人员来说，你很难保证开发出来的产品没有bug，对大规模数据库的运维DBA来说，你也很难保证自己永远都不会犯错，引起运维故障。尽管我们有十几年的运维经验，小心又小心，仔细又仔细，认真又认真了，常在河边站哪有不湿鞋。棋圣聂卫平干了一辈子围棋，被阿尔法狗换个昵称变成Master就轻松打败了。同样的，我们的眼光要更高一些，让DBA站在狗或Master肩膀上。所以我们逐步研发了数据库性能管理平台、SQL审核平台、数据生命周期管理平台、数据架构管控平台、大数据日志分析平台，目标就是让DBA回到上午喝杯茶瞅一眼，下午继续喝咖啡的生活中去。

我从事大型数据库技术超过20年的经验，从事团队管理和数据库管理有超过20年以上的经验。

我认为DBA可以分为运维DBA、开发DBA以及混合型的DBA。一般来说，运维DBA侧重于数据库的安装、配置、运行和维护，分为初级、中级、高级、大师级；开发DBA侧重于数据开发和设计，如表设计、索引设计、存储过程、SQL编写和优化等，也分为初级、中级、高级、大师级；而混合型的DBA兼具开发DBA和运维DBA的工作能力， 并在数据库运维中将应用特点与数据库特点结合起来，帮助设计提供专业的应用表、索引、存储过程、SQL语句设计，同时具有专业的数据库知识和技能，并进行应用系统数据库设计从开发到生产部署无缝转换，保障应用的设计和运行要求在数据库生产部署中体现出来，混合型的DBA也分为初级、中级、高级、大师级。

顶级的DBA应该是混合型的DBA，在工作中跨架构设计、开发、部署、运维、优化和持续优化全流程发挥作用， 并精通Unix、Linux操作系统，精通性能优化，精通硬件性能和设计部署， 精通数据库内部的工作机制，对于SQL语句、执行计划、表、索引、锁、并发等有深入的研究， 并能熟练编写shell脚本等，如有其它编程能力更佳。

最后，优秀的DBA也需要具有良好的数据安全行为习惯、良好的沟通和团队合作习惯。

我是一名金融企业的DBA，工作四年啦。早年以Oracle数据库运维为主，现逐步转型到MySQL方向。传统意义来讲，MySQL DBA是从事MySQL数据库管理和维护的技术人员的统称。随着互联网的兴起，业务系统对数据访问的要求越来越高，对于数据库的应用场景也越来越复杂，所以，一个合格的MySQL DBA不仅要精通MySQL数据库本身，更需要深刻理解从底层的操作系统原理，到顶层的数据库架构设计每个技术细节；还要做到与时俱进，对新技术要保持敏锐的嗅觉，保持高水平的学习能力，才能更快速的应用新技术，从而满足对数据库更高的要求。

DBA在外行看来可能很牛，他们认为DBA="吊逼啊"，我经常自嘲DBA="逗比啊"，所有的神枪手都是子弹喂出来的，喂到吐，喂到把坑填平了。

DBA在随着IT行业日新月异的快速发展着，从独家垄断的商业产品到百家齐放的开源技术，从传统中心到云，从传统库到大数据，从集中到分布、从几台到几万台、技术和产品不断地面临着社会和各行各业发展带来的层出不穷的新挑战。DBA的工作边界在扩大着、轮廓日渐模糊、问题多了、复杂了，同时可以做的事也特别多，机遇也随之而来的变得更多。
   

DBA在面临新的技术需求、新的技术生态圈、新的架构、新的发展模式、新的组织形态、新的竞争领域、新的困难还有随之而来的新机会一直在带来新的挑战和新的机遇，时代一直在发展，不论是个人还是组织都在处于逆水行舟、不进则退的境地中。所以感觉一定要随时学习、及时学习、处处学习、不断学习、坚持学习，保证自身的价值和竞争力，不断接受新思想，掌握新技能，与时俱进，多向人讨教，及时自省，不断突破自己的格局，扩展自己的眼界。

我是一个金融行业的应用DBA。我认为，对于使用成熟商业关系数据库（如Oracle）的应用DBA，完成系统功能，满足系统性能需求，同时兼顾系统维护性、扩张性，这样的DBA可以算好的应用DBA。满足系统功能需求，这是对DBA的基本要求；后面几项就很难做到，也很难度量：性能不足硬件补，不容易维护可以通过增加人手解决，不容易扩展就重新建个新系统，都有解决办法，表面看起来都很合理。但好的DBA会综合考虑这些非功能需求，只不过价值很难体现罢了，这是DBA职业的重要特点。

专精于性能调优、可以快速解决生产环境的的DBA也算好的DBA。对MySQL源码熟悉，可以根据需要修改，也算好的DBA。合理使用各种NoSQL数据库，基于开源技术低成本、满足业务需求的DBA，也算好的DBA。

SQL Server DBA一名，从大学接触SQL Server到现在有9年时间，毕业之后在工作过的公司用过SQL2000，SQL2005，SQL2008，SQL2008R2，SQL2012，SQL2014。

在毕业后的第四个年头踏入DBA行业，可以说SQL Server是比较容易入门的数据库，因为SQL Server只能运行在Windows上（2017年中会发布Linux版 嘻嘻），Windows又是比较傻瓜和简单，所以往往让人对SQL Server造成误解，比如性能差，太简单，并发度低，不能hold住大数据量。

最深刻的是刚做DBA的时候，公司做大数据分析，生产环境有好几个单库超过10TB的SQL Server数据库，用的版本是SQL2008R2，对于一个DBA菜鸟来说确实很棘手，后来慢慢找到套路之后发现超大型数据库的管理方式跟一般数据库的管理方式的差异，比如说不做备份，只做数据库镜像，使用分区表归档老数据，使用发布订阅方式迁移数据库等等。

现在除了SQL Server平时也会学习其他数据库，比如MySQL，MongoDB、Redis，毕竟随着公司使用的数据库类型越来越多，其他数据库也需要维护，总之SQL Server是一个不错的数据库，投入进来学习总会有很大的收获。      

我是一名职场准新人，接触数据库一年多。因为工作需要，接触到MongoDB和Redis等非关系型数据库。初次接触感觉短小精悍，解决了很多Oracle环境下不适用的场景，同时又不像Oracle那么矫情。各种参数设置比较简单，故障场景也比较少，最差的情况莫过于重启，反正不会起不来。接触久了就会越来越觉得自己的无知，当下环境，各类数据库风起云涌，应付简单的需求场景还可以，但是若要深入到优化层面，那不多的参数，选择少了，难度大了。大多数的NoSQL数据库都是近几年新兴的，网上可查的资料少之又少，但版本更新却是一个比一个快。若想在NoSQL DBA的这条道路上走得更远更深，还是需要懂一些开发，耐得住寂寞，从源码级上去深入研究。路越走越远，坑越踩越深...  

早年曾从事过一段分析型数据库(GreenPlum)的运维工作。与大家常见的数据库不同，这些相对小众的数据库往往是"小而美"的。它们往往有着鲜明的技术特点，非常适应于某个特定领域。例如我接触过的GP，就以其弹性扩展能力(MPP架构)、强大的处理能力(分布式)、标准的SQL接口等，成为分析型数据库的一个不错的选择。作为这类数据库的DBA，其技能的要求也有所不同。从个人角度而言，也是一个一段不错的成长经历。从整体数据库发展来看，"大而全"的数据库将不会存在，在每个分支领域，都有各自擅长的数据库产品。对于DBA来说，应对各种业务需求，选择合适的解决方案就是DBA的核心价值之一。

一直从事数据库内核开发，现在在MySQL InnoDB团队负责新功能的开发。在我看来，一名优秀的数据库DBA应该具备这样一些素质：

1、对数据库的基本理论有着深刻的认识。

作为数据库的主要操作和使用者，对于数据库的一些基本理论，比如：关系数据库的事务处理，存储管理，内存管理等等有着深入的了解，这样在面对不同的数据库时，就可以非常清楚其内部架构和对数据处理的流程。
 

2、对各种数据库产品的功能和特性有着详细的了解。

当今的数据库产品非常丰富，每一款数据库都有其自身的特点。比如，有传统的关系数据库，有内存数据库，有KV数据库等等。作为DBA，需要对各种数据库产品的特点有着清楚的认识，从而能有针对性的采用不同的数据库产品来解决不同应用场景的问题。
 

3、对数据库的各种应用场景有着比较深刻的理解。

对于数据库的使用，针对不同的应用场景有着不同的配置和使用方式，比如，怎么设置备份，怎么设置主从复制，怎么设置各种参数来使数据库的性能最优等等。
 

4、具备一定的扩展开发能力。

当前的DBA所要面对的系统越来越庞大，多节点，多实例，云环境等等，使得数据库的管理越来越复杂。这就需要DBA能针对自身工作的特点来设计和开发有针对性的管理工具。通过这些管理工具来简化和优化管理工作。这也就是我们所谓的DevOps。

我是一名系统工程师，从事IT行业7年了，从事过零售业、电力、银行系统运维工作，2014年拿下了RHCA。

我认为DBA属于运维工程师的一个分支，主要负责企业的数据库监控管理、数据库性能调优、数据库故障管理、数据库安全保障等。

随着云计算、大数据、自动化运维的蓬勃发展，越来越多的开源数据库的涌出（如NoSQL、MariaDB、PostgreSQL等）对于数据库人员是一个很大的技术挑战，只会一种数据技术，已经不能满足企业人才的需求了。

据我了解现在大部分企业已经开始进行自己云部署，把公司应用、部分开源数据库上到云上，提高使用率、高可用率等。并且现在的公司对自动化运维也有非常高的认可，所以DBA人员以后的发展是不能只会一种数据库，要多学习一下主流及开源的数据库，熟悉一下自动化运维工具及开发（如Python就很不错）。

我是一名具有多年工作经验的开发人员，目前从事大数据相关开发工作，大数据领域多为非关系型数据，存储也变得多元化，DBA需要和开发人员一样不停的学习新知识去面对各种不同的环境，同样是与数据打交道开发人员和DBA不同的是对数据的关注点不同，开发人员从事的是对现有数据进行转换、分析、挖掘并提供相关服务，DBA是运维的一个分支，负责保证存储系统高效、稳定、可靠的运行，这是一切数据服务的基石，Dev和Ops的紧密集合是系统稳定运行的有力保障。

作为一名从传统关系型数据库的DBA转到大数据行业的从业者，也来谈谈我现在眼中的DBA应该具备的能力：

1、拥抱开源

现今，作为一名DBA，不管从自身能力发展，还是整个互联网行业的变革，单纯的只了解一种数据库技术，显然已经不够了。各种的开源技术给现今的互联网行业带来了很大的变革，传统数据库技术与Docker容器技术结合，与Openstack云计算技术的结合，都给我们的运维模式带来了不小的改变，DBA需要不断的进行学习，跟进这些先进技术。

2、需要具备有一定的开发能力

DBA还是属于一个运维角色，很多的数据库从业者刚入行就从事DBA这样一个工作，往往忽略了对开发能力的积累。现在讲究的敏捷运维DevOps，DBA需要具备Python或者shell脚本的开发能力，通过构建一系列自动化运维的脚本，来提高自身的运维效率。以满足当今爆发性增长的运维的需求。

我是一个有近20年经验，玩硬件出身的技术人。我主要关注存储、服务器领域，偏技术市场的工作性质吧。这些年来有幸结识了不少DBA专家朋友，学到不少东西。曾经看到同行说搞存储离不开对主机（操作系统）、数据库方面的知识，反之亦然。有朋友认为在云计算时代越靠近业务上层越吃香，从这一点感觉DBA比主机/存储运维工程师的前景还是要好，我也看到有些朋友成为了名副其实的DevOps全栈——在今天很抢手的人才。不少DBA朋友在闪存存储、双活容灾等方面积累了丰富的实战经验，这也是令人羡慕的。

信息化时代什么最值钱，答案是数据，而对于结构化数据往往又是重中之重。不过对于大多数单位来说，并没有专门的DBA职位，往往运维人员身兼数职，身上的压力很大，只要系统应用不出问题就烧高香了，要调优？没有实操经验，纸上谈兵，谁也不敢，除非真的出问题，不得不改动。有专职DBA的单位则在这方面的维护操作方面更有自信和把握。
 

我也接触过几位DBA牛人，对高手的感觉就是基本功很扎实，知识体系化，做事规范，分析问题很全面，还有的德艺双馨，出问题不会推诿，敢于担当，以解决问题为己任。