七年或者八年或者很早之前，DBA是非常吃香的职业

　　讲这个，大概要从系统的性能瓶颈说起

　　很早之前，互联网刚开始的时候，算是蛮荒时代

　　那时候大家写代码还没有规范，能把功能做出来就不错了，大家拼的是什么呢，Sql的性能

　　基本上就是没有中间层，也不会分什么服务层和Web层，很多时候SQL都写到页面上

　　然后Sql呢，又属于那种外键，视图，存储过程的天下

　　这就导致了出现一个问题：大部分的功能都是通过DB来实现的，也就是说，什么计算啊，分组啊，排序啊，筛选啊，全是靠DB来做

　　小功能还没问题，功能一多，问题就出来了，一个Sql语句执行了半个小时没做完，然后整个系统崩溃掉了

　　那么，怎么解决呢，解决的方案就是。。。。

　　我其实很难理解这种思考方式。。。。

　　就是找一些人，对DB特别熟悉，他的职责就是审核所有程序员的Sql语句，去找出来这些Sql哪些用到索引了，哪些没用，能不能执行，怎么优化，以及监控线上的慢Sql

　　一个公司能养得起DBA的，很NB了

　　很贵的！

　　所以这是那个时候的DBA，但是，很快大家发现有不同的方式了

　　这种方式就是，我靠，原来我可以用分库分表，我可以做读写分离，我能做主从

　　于是对于DBA的依赖又重了一些，再加上数据的安全和备份，所以DBA的作用已经有点偏移

　　然而最关键的还是系统架构的发展变化了

　　分布式的概念慢慢的起来了，大家明白了一件事儿：

　　机器不够，并不是说把服务器升级成小型机就能搞定了，而是应该用更多的机器来做

　　因为便宜，而且更简单

　　所以后台的系统架构慢慢的演化出来很多不同的层

　　WEB层，服务层，缓存层，DB层

　　对于缓存的使用越来越重要，由此而变化的观点就是数据分成了缓存和持久两种结果

　　DB慢慢的变成了持久层-也就是说，只是要把数据持久化，并不希望它去承载用户的压力，缓存主要用来扛并发，不需要做持久

　　这是一个很关键的点，也是决定DBA命运的转折点。

　　当然现在还看不出来

　　（像MongoDB，Cassandra，这些，又是另外一种不同的技术走向，包括Mysql也在不断的想要提升自己的性能）

　　所以这些东西我们先抛到一边不谈

　　只说这中间发生了一个变化，对于后端人员来说，对数据库访问的变的严格起来了

　　尽量单表操作，不允许复杂查询，设计架构的时候必须考虑缓存

　　甚至我们在白社会的时候（老大曾经是在搜狐做白社会的，那个时候还是三大门户网站的时代）还设计了一套通用的DB访问机制--虽然是七年（九年）前的设计然而现在一直都觉得很赞

　　只是再也没有如我在搜狐的时候那群人做这些事了-反正我见识少，一直在小公司混，也不怕你们嘲笑我见识少。

　　这样就导致DBA的一个很重要的工作职责失去了意义：

　　查找慢Sql

　　因为我们在系统架构层已经决定了不再这么使用DB

　　这样使得Oracle什么的也慢慢的失去了价值-我知道我说的每一句话都有可能会引起争论

　　所以我不得不再次强调一次，纯属个人的脑残关点，不喜欢的话，要么认真的回复来打我的脸教我做人我认真学习，要么就是滚远点表理我

　　包括建表，去除外键，去除事务，去掉视图等等等，一瞬间，DB的使用简单多了

　　那么，DBA还能做什么呢？

　　对于我现在的理解来说，DBA的职责慢慢变成了数据备份和安全策略--然而这部分又跟运维的工作有了冲突

　　所以在某种程度上来讲，我都会在五十人左右的公司把DBA安排到运维部分，跟运维的兄弟们做基友

　　可是现在云服务器也变的越来越好用了，这里也推荐一下好友的金山云和Ucloud

　　阿里云跟我并没有神马认识的人，所以不推

　　DBA除了之前提到的主从，读写，数据备份，权限控制，分库等等，还应该再扩展视野

　　把MongoDB，Redis，memcache，elasitcSearch，hadoop等等这些数据全部管起来

　　我觉得，更像是一个运维的分支了

　　这就是我目前认可的DBA的价值和意义，已经从之前的性能优化部分转移到了数据备份和安全

　　毕竟，性能，架构，和优化这些东西，是离不开业务系统的

　　那么，接下来，和之前一样，继续介绍一下DBA的工作内容

　　工作内容

　　如果你做了一个DBA，基本上会遇到两种情况

　　一种是你的后端工程师懂架构，知道怎么合便使用DB，知道如何防止穿透DB

　　那么恭喜你，你只是需要当一个DB技术兜底的顾问就好，基本上没什么活可以做，做个监控，写个统计就好

　　你可以花时间在MongoDB了，Hadoop了这些，随便玩玩儿

　　再按照我之前说的，做好数据备份，如果需求变动比较大，往往会牵涉到一些线上数据的更改，那么就在发布的时候安静的等着，等着他们出问题。。。。

　　如果不出问题就可以回家睡觉了

　　另一种情况就是我刚刚提到的，大部分程序还是靠SQl

　　然后有时候DBA还需要写几万行的存储过程，那么你的主要职责还是优化Sql，优化Sql，永远不停的优化SQL

　　嗯，就这样

　　还有就是多花点时间把MongoDB和hadoop这些都维护起来

　　或者简单说，只要跟数据安全，备份相关的东西，都维护起来

　　需要技能

　　环境【Linux，Mysql，Oracle，MongoDB，Hadoop】

　　工具【各种DB的版本，工具，备份，日志等】

　　这个说是环境已经有点勉强了，毕竟是一些吃饭的家伙，就是各种DB，各种维护什么的

　　工具也是相关的内容，再强调一下对版本的熟悉程度。

　　马丹我感觉我没什么可说的了

　　因为刚刚又被 “我就静静的发图～_java吧” 这个贴子恶心到了

　　我被Java吧封了，然后他们还@我，我要赶紧写完然后想办法去跟他们对骂去

　　（这是老大准备创业前写的帖子...囧，老大还是这么真性情）

　　发展前景

　　DBA的发展前景我说不好

　　一些简单的工作，运维也是慢慢学会了

　　包括薪水，这个是我比较没把握的

　　之前的薪水都是有迹可寻的，DBA的薪水我接触的比较少，实在是没什么底气

　　1年~5年：8K~25K

　　5年以上：20K~40K

　　（我好心虚。。我只给一个DBA开过工资）

　　成长路径

　　也不知道有啥成长路径，感觉这个职业的物种越来越稀少了

　　入门门槛

　　DBA的入门门槛也是比较高的，而且，很少于有刚工始就是做DBA的，大部分都是工程师转的

　　所以呢，至少要两到三年左右的时间才有可能做DBA，才能负责一些相对负责DB的事情

　　哪些行业适合做DBA

　　IT界：后端工程师，运维工程师

　　其他界：无

　　其他行业的想转DBA，刚刚也说过了，不合适，只能先写代码，再慢慢的转

　　职业限制

　　这个职业最大的限制大概就是。。很容易无事可做

　　前面有后台架构师蚕食，后面有运维工程师侵入，中小公司都不太会设置这个岗位

　　所以有的时候会比较尴尬，大概还有一些外包公司，或者是传统的IT企业，会是由DBA去设计表，去理清业务还有一些岗位，其他的都不太好

　　所以对于其他的各种持久化数据的备份和优化，特别是对一些正在使用的框架，又不够成熟的东西，更容易找到自己的位置

　　如果你要做DBA的话，就记着，跟持久层相关的优化，数据安全，备份都要去了解--顺便再学点运维的东西

　　去哪里学，怎么成长

　　基本上，DBA可以由运维工程师和后台架构师去转，也会有一些数据库方面的认证之类的的过程

　　这个岗位啊，跟其他的岗位真心有点不一样

　　很少有刚毕业或者刚入行的人就要去做DBA的--你也做不了亲，跟数据相关的东西，没个三年五年的经验，真的很难做

　　而且有些技术细节，是必须要了解的比较多的

　　PS：刚刚想到了，云服务器里是DBA的一个好去处，其实这里跟大数据也有一些相关的

　　这么说的话，DBA的职业需求度跟云服务器公司的发展是有比较密切的关系

　　但是总之，不太可能变成一个标配了

　　想要学习编程的同学可以加Q群：562814359

　　也可以点击下面链接

　　www.jnshu.com?source=souhu

　　来官网逛一逛，师兄师姐的学习日报全部可以查阅学习，还可以私信勾搭哟