从2014年从事DBA工作以来，有6年时长，最近面试几个人，有所感发。
一是备份重于一切。这是个老生长谈的话题，记得自己都救火多次了。如果你是一个DBA，出了故障无法恢复，“悟空，怎么能没有备份呢。没有备份这就是你的不对了，就算没有DataGuard，database mirror或replicate 之类的，总得有个物理备份吧，没有物理备份总得有逻辑备份吧。啊？这些都没有，那怎么能降妖呢，那就去赶紧回去菩提老祖那里闭关吧，省得被妖精炖汤喝了”。各位亲们，备份恢复基本功得扎实，搞清备份恢复的原理，至少的搞清热备，冷备，全备，增备，部分备份及其恢复，以及各自的优缺点，适用场景等等，这是DBA起码的一点要求，这样才能逢凶化吉，幸免于难。总有很多朋友问到这些原理性的东西，不过很抱歉，很多时候难以一一回复。建议大家多看官方文档，结合数据库体系结构，结合实践，举一反三，很多问题就无师自通了。
二是架构决定一切。
数据库的架构是涉及数据库性能至关重要的一环。高可用是我们见过和听过最多的同时满足RTO和RPO不可缺少的部分，达到5个9。
如果要提高吞吐，实现负载均衡，自动故障转移，RAC ，Xtradb Cluster或MGR 都是不二之选。
如果要提高性能，可以基于备从库备份，实现主备从库读写分离，以及分散I/O。当然解决性能问题远不止这些，诸如使用滑动窗口分区表，物化视图，创建高性能索引，使用memory引擎，memcached，启用in-memory特性，乃至到最初的业务逻辑设计，数据库设计。
写到这里让我想起了体和用。什么是体，关系性数据库来源于关系代数，就是连接，投影，选择，就是集合，这些可以看做体。更进一步，所有关系型数据库需要解决的是数据的封装即存储;数据的一致性即事务;数据的读写即SQL优化器的模式;数据的完整性即备份恢复以及数据库的并发，这些是数据库的体。各大关系型数据库厂商用他们特有的方式解决了这些难题那就他们的用。
对DBA而言，任一数据库体系结构(即原理)是体，基于其上去设计部署数据库是用。有体有用，体用一如。因此良好的架构设计是将数据库发挥到极致的关键。相对复杂的是mysql的架构，都是七拼八凑，诸如drbd+heartbeat，keepalived+mha，mmm，haproxy ，fabaric ，ndb，xtradb cluster ，galera cluster，MGR。
还有N多叫不上名的第三方开源工具了。因此结合自身的业务，以及不同架构的优缺点，应合理地使用相应的架构。即结合自身业务将工具的优点发挥到极致来部署你的架构。选择架构是要根据业务特点外，还要根据企业的经济实力，自身对技术能力熟悉程度，以及该架构的运维成本，难度。最后要看架构是否成熟，是否有大厂背后支持。
比如拿MYSQL 8.0的MGR 和PXC 两个集群来看。MYSQL 8.0 MGR 搭建容易，易学易用。PXC就非常难。学习成本高。不过MGR后期运维技术难，有一大堆的参数相关。
从性能方面PXC高于MGR，MGR比单价能力降低了40%。这个ORACLE RAC类似。
MGR后面有甲骨文大厂。PXC后面是小厂。选择的话，如果追求高稳定，并发事务低，可选择MGR。对稳定稍微小点，对并发能力高点，可以选择PXC。对高并发，还是选择传统的主从 GTID，一拖3，或者一拖1 并级联3个从库。完成高可用，高并发，读写分离。
三是责任心高于一切。最近的几起DBA删库事件，比如腾讯云和顺丰科技，对客户造成了极大的损失，为此客户对腾讯告上了法庭。顺丰损失了5T数据。 我想这责任DBA也有份，而管理层极度缺乏社会感与责任感。顺丰科技把人当996工具，一个90后就当上了高级运维开发工程师。一人兼职数职，运维，开发 MYSQL DBA！而且还是晚上加班干活导致的。 哈哈！对企业而言，没有一个老板愿意把他们企业的核心命脉，数据，交给一个缺乏责任心的人，这就好比定时炸弹，随时会有数据库崩盘。因此练就良好的心里素质和高度的责任感给老板安心，给自己欢心。因为这里边蕴藏了无限的机会，而不仅是一个DBA需要具备的。任何一个岗位都离不开它，乐于奉献，敢于承担，止于至善，在平凡中见证伟大。尤其是这点，说易行难。做到并非易事。
四沟通重要一切。如何表达是关键的问题，面试那么多90后，对技术表达比较含糊，东一句西一句拼凑起来。要完整表达是衡量你对技术整体把握能力。抗怼，别人通过语言来挑起你的情绪，从而让你做出了领导不喜欢的事情。或者是表达了不该的情绪。这样其他同事对你的抗压能力表示质疑。
五服务领导高于一切。 领导是衣食父母，在家靠父母，出门靠朋友，打工靠领导。搞好领导关系，才能做好DBA。否则关靠技术牛逼也没有用，无法长期做稳DBA大佬职位。没有长期稳定的工作时间，难以积累技术，也不用说谈发展。什么监控？什么自动化，什么容器，以及现在流行的AIOPS，或者源码DBA！
