MySQL方向工作规划的一些思考

这是学习笔记的第1938篇文章

最近行业里真是动荡，每天都能听到哪里裁员了，或者叫做裁撤，动静都挺大。 其实对于我们的工作来说，我们需要好好的反思下自己的工作了，现在是你想多干干好点，公司有没有这个平台，有没有这个机会，从这个角度来说，时间对于我们来说都是很紧凑的，而且从时间成本来看，会带来一种略微浮躁的心态和工作环境，那就是短期性价比不高的工作会被搁置，短期性价比不高，长期性价比高的工作短期内也不会被看好，现在要的都是快，能很快看到效果或者预见到一些成果。

我也做了一些反思和总结，我觉得目前存在一些明显的问题，那就是大家的工作和生活短期内被事务性工作包裹，短期内大家看不到太多的成长空间。这是一把双刃剑，有很多事情要做，但是我们却没法要求更多的资源，很多时候都是依赖当前的资源成本，要不提高资源的使用效率，要么就是充分利用人员的精力去聚焦一些事情。

总体来说，我们可以设想出很多的目标和计划，我们需要明确的一个核心点可能不变，那就是我们是DBA团队，而不是其他的运维开发团队，DBA团队的一个核心能力就是提供SQL的优化建议，这个事情如果从时间成本和周期来看，很容易被忽视，但是在聚焦本职工作的时候，我们需要把本职有共识的工作要做深做好，比如我们把一些数据操作效率提高，这个没错，严格来说，这个不是DBA工作的核心竞争力，换其他部门去支持也能搞定，但是换一个部门却搞不定SQL优化的专业建议，所以在目标和计划上，需要聚焦，哪些是我们的本职工作，我们要做扎实做深。

还有一些工作需要重点考虑，但是其实从规划的时候就能够预见到基本的结果，比如数据恢复能力，这很容易被理解为DBA的本分工作，本分工作你做到了8分，9分，那是你应该做好的，只是做出的效果更令人满意，但是这个工作的输出意义却相对薄弱，在这个地方也是很多技术支撑团队理亏的地方，事情做了，但是从业务的角度衡量却很难以体现有效的价值，这种事情上，说明我们前期想的还不够彻底或者把这个事情的意义彻底掰扯透了。

这种类型的事情，我觉得可以树立一些明确的输出目标，让这个事情带有一些挑战，同时也更加好衡量，比如备份没有恢复的场景，备份的意义会大打折扣，那么恢复的场景不应该是被动的数据恢复，我觉得可以做一些延伸，把恢复的价值最大化，比如有如下的一些场景可以很好的用到备份的一些沉淀：

1）数据恢复流程化，自动化，如果数据恢复能够通过平台化操作完成，这个事情的复杂程度就会低一个层次，更加容易上手。

2）将备份和性能联系在一起，在我们常做的工作中，如果碰到大表的变更或者数据操作，我们其实很难给出一些明确的指标意义和评估标准，比如这个表的数据量在5000万，做DDL变更显然是有性能隐患的，但是这个操作我们如果在线上要做，到底影响时长是几分钟还是10几分钟，我们其实可以很好的使用备份来弥补数据的这种空白。

同时在技术深度上也需要我们积累大量的实践经验，比如中间件技术，我们是否具备了中间件技术的可控程度或者定制能力，在中间件技术的发展过程中，它在某种程度上的意义会本身大于数据库技术本身。在这一块我们需要持续的投入一些工作。

在MySQL协议和高可用建设上，MySQL方向可做的事情依然还有很多。这些是一些偏底层技术设计的工作，相对会比较固定，但是从技术体系上来说，需要持续投入的精力和工作能力。

当然我们所做的工作不能局限于是MySQL还是Oracle还是其他数据库，要带着一种全新的角度来看待，而不是只是做业务的接入，要基于业务场景建议合适的模型，不断的迭代改进，让设计更加鲜活有落地的场景，这也是我们工作中难以被替代的角色和能力。

今年你的工作都计划了哪些，有哪些你觉得很有深度和难度的工作，不妨在末尾留言，我们可以进行一些讨论。