今天不聊技术细节，写篇闲文，说一些数据库方面的个人感想。
分布式数据库的分布式能力，相比传统数据库，在性能扩展、数据搬迁、高可用方面多了一些不一样的解决方案。客户根据自己的需要选择。有的场景不需要分布式，比如说 OA 业务，用达梦数据库替换一下，改动成本小。换了后少折腾，也可以稳定的运行下去。有些业务场景就很复杂，如要处理的数据量大、或者某些时间段并发高、或者时效性要求高、或者延时要求低等。那就不是简单的数据库替换就可以满足。这个时候很考验数据库的综合能力。
分布式数据库的分布式能力，很有可能出现跨机的请求，会导致业务请求延时增加。所以很多分布式数据库都有各自的技巧去规避分布式。这也是一种合理的优化。不过，如果把分布式数据库都当做单实例单机去用，如果不是产品能力受限，就是大材小用。
规避分布式的做法之所以是合理的，历来就有。比如说 RAC 集群的最佳实践就有一条，尽可能不同业务通过不同的节点去读写数据，减少节点间的数据传输（CACHE FUSION）。这只是建议，业务能做到的比例很小。业务使用数据库往往不考虑这么多，需要架构师和 DBA 指导使用。分布式数据库也是同理，尽可能的减少分布式 SQL 在总 SQL 中的比例。
分布式数据库的架构相比传统数据库都有一定的复杂度，所以部署和使用门槛都普遍很高。就目前而言部署最方便的我看还是 TiDB 。不过部署难并不一定是坏事。二十多年前 ORACLE RAC 部署难度也非常大，早期不少 DBA 因此拿过不少外快。正因为难，所以给DBA群体一些机会，DBA需要额外的花些精力去钻研。当然如今分布式数据库有原厂的支持和推广，想靠部署这个赚外快是很难的，但是分布式数据库的三方运维还是有很多商业机会的。这一条完全是站在三方运维的角度感慨的，其他角色的朋友见谅哈。对于 DBA 从业者，这是一个好的机会。如果每个数据库都像 MySQL 那么简单，很容易让人产生“人人都会MySQL”的错觉，最后容易出事。分布式数据库由于架构理念有很多新东西新挑战，是要花精力去学习的。有传统数据库运维经验的人学起来会容易一些，感受也深一些。所以，难不是坏事，不难要“你”做什么。
DBA 工作跟老中医一样，一直如此，经验越多越香。这个经验不是单纯的工作时间，而是问题处理分析经验。而分布式数据库往往不成熟不完善，客户使用的问题就多。这些问题有些是客户自身的有些是产品的，问题定责的时候可能还有拉扯。对于中间的当事人DBA而言，都是修炼的机会。当然事情也有个度，如果问题很多，DBA处理非常耗精力搞垮了自己，那确实是得不偿失。如果问题很少，DBA只是日常看看监控巡检偶尔查查问题给原厂提提工单，那也是失去了技能晋级的机会。当然对于并不追求技术的管理者而言，前面这个理解是不对的。管理者要的是结果，平稳最好。能做管理者的是少数，管理者也有管理者的难。
DBA 工作随着自动化技术的发展出现一些改变，现在又有 AI 大模型的介入，总是有种让DBA失业的传言。个人认为这些技术可以帮助DBA从一些低层次的信息收集和分析工作中解脱，专注于分析思考问题的关键。分布式数据库在这方面做的都不错（为了突出创新，就像新能源车都大力宣传自己的车载屏幕多么好看功能多么智能一样）。有这个技术很好，但也不要忘记数据库运维的本质。
对于问题很少的局面如何破呢，那就是没有问题就主动“找问题”。当然，找问题不是“惹事”，是去观察线上数据库的性能变化，联系数据看上对应的业务，去推测彼此的联系。如果线上环境真的没事，那就测试环境多折腾。多观察这样的事件：如果 A 发生则 X 发生；如果 B 发生则 X 发生；。。。。。。 从逻辑上来说反过来 如果 X 发生了，并不能肯定 A 发生 或 B 发生了。但是可以说如果 X 发生了，有可能是 A 发生了，也有可能是 B 发生了。甚至可以说 A 发生的概率更高一些。DBA 干的就是这种或然性的推理。有些复杂的问题找原厂研发分析，也是这个逻辑。专家是什么，专家就是推理准确性稍微高一些。当然，如果专家多次判断失误，就会被喷为“砖家”。这个也正常。专家也会失误。原因有很多。或者是新的场景、或者是别人提供的信息不当或不全。没有哪个专家分析问题能百发百中。就像没有哪个神医能一看人就准确说出病因。
专家资源总是稀缺的，原厂专家的资源精力也是有限的，不是所有的客户都能享受到原厂专家服务，所以三方运维有机会。（当然从经济角度来说当大家都涌入这个赛道的话，又会拉低这个收益和质量。）传统的数据库三方运维的质量一直不高也是这个原因，分布式数据库的三方运维质量也不高是人才稀缺和运维理念落伍导致。客户甲方总想驻场能力这样会那也会，大部分也是妄想。普遍来说，驻场的质量跟客户在三方运维上的投入（金额）是成正比。这是经济学规律。当然由于信息的不流通、人员关系的复杂，也存在一些偏离规律的案例。有些客户有福了，有些客户遭罪了。
分布式数据库毕竟还是数据库（这里特指关系数据库），关系数据库的理论很多还是适用的。客户以前积累的数据库运维和开发经验也是适用的。比如说数据库变更要严格规范，数据库要有高可用方案、有备库还要有备份等等。数据库开发时并发高的查询要尽可能的快（优化性能，如改变业务查询条件、或者加索引）、跑批的事务不要太大要分批提交等等、表要有主键等。大的查询到只读备库上去查询。此外，一个好的数据库监控产品也是必不可少的，原厂的运维监控产品目前普遍还是最好的（没办法，生态没有成熟之前，不会有优秀的三方数据库监控产品）。
这些都是过去的经验，经验是好但并不是每个客户都严格遵守。比如说有些客户的数据库没有备库或者没有备份，出问题的时候着急了花钱找人修复数据。也比如有些跑批实现方式就一个 UPDATE 更新几百万几千万，让数据库去扛结果有时候数据库没扛住报错了。有的客户是选择性的遵守。比如说碰到查询性能不好就建索引，一个表上面十几个索引，很多还是单列索引。索引这个东西往往只看到它的好，不管它的代价。加一个索引人人都会，但是删一个索引或者合并优化几个索引，就很少有人敢拍板。
这些 BAD CASE 在传统数据库上可能很容易蒙混过关，但是在分布式数据库上很容易出大问题。所以有些人会喊“国产数据库不行”、“分布式数据库不行”。厂商有厂商的观点，客户有用户的观点，彼此会有拉扯，完美的和谐是不可能的。所以看一个分布式数据库的成熟度，客户都会看案例。看哪些案例开始用了，就知道这个平衡点到哪了。不管怎样，对于DBA，它就是个机会。
对于客户，还是要严格执行以前的数据库开发和运维规范，还要加入分布式数据库特有的规范，能规避大部分不该出现的问题。做好自己能做的，剩下的就交给老天了（或者说交给原厂了，这取决于产品自身能力）。趋势是原厂会大力培养生态，减少客户的这种显性依赖。原厂也要大力往前跑😄。
以上纯属个人观点，不排除有“歪理”成分，大家一笑而过。最后顺便打个广告，因公司业务发展，可能会在杭州、上海、深圳、广州等城市有一些 OB三方运维服务，欠缺本地人才。欢迎可能有这方面需求的DBA伙伴跟我保持联系，希望能有机会成为同事（一半机会看OB发展😄）。
