数据库管理-第276期 2024最后吐个槽（20241227）

作者：胖头鱼的鱼缸（尹海文）
Oracle ACE Pro: Database
PostgreSQL ACE Partner
10年数据库行业经验
拥有OCM 11g/12c/19c、MySQL 8.0 OCP、Exadata、CDP等认证
墨天轮MVP，ITPUB认证专家，数盟会长老会成员，OCM讲师
PolarDB开源社区、青学会MOP社区技术顾问
HaloDB外聘技术顾问
OceanBase观察团成员
IF社区联合发起人
圈内拥有“总监”称号，非著 名社恐（社交恐怖分子）
公众号：胖头鱼的鱼缸
CSDN：胖头鱼的鱼缸（尹海文）
墨天轮：胖头鱼的鱼缸
ITPUB：yhw1809。
除授权转载并标明出处外，均为“非法”抄袭

最近又接触到了一些和数据库相关的一些事情，感触良多，忍不住吐槽，默认都和本人实际工作没有关系，请身边人仔细鉴别。

1 换数据库简单

一个朋友跟我说，他的客户是如是说的（经过加工和总结）：

数据库都一样的嘛，买来安装上数据弄过去就可以换了，很简单嘛

今天恰巧我的一个客户跟我聊天时候说到“当年从HP小机11g迁移升级到Exadata X8的19c上我们都搞了大半年才弄顺畅，相同产品的不同版本尚且如此，换数据库的难度可想而知”（如果大家有兴趣可以去翻翻我古早的文章）。当初我这里算是最早吃螃蟹的（上19c），众所周知，Oracle 19c初期版本BUG多的出奇，而我又踩了很多BUG，其实如果我缓缓上19c可能真还没那么多问题。
其实我还想补充一点，那次迁移并没有遇到换数据库最大的问题：应用改造，这里我重新总结（科普）一下，为什么即便是兼容性高的发指的数据库，都需要耗费较多的成本进行应用改造：

• 数据类型支持的区别：不同的存储引擎、数据库设计、数据库限制等能支撑的数据类型、数据类型的长度、表宽度等都是可能存在不同的
• 底层存储不同：比如常见的B-Tree、Heap、LSM Tree等，不同的底层存储的注意事项、性能表现、硬件需求、硬件利用效率都是不相同的
• 优化器的区别：很多时候，不同的数据库即便是支持在相同数据下可以运行一样的SQL，也会因优化器的能力表现出不同的性能，这些都是需要进行调整的
• 数据库架构的不同：集中式向分布式（分片）数据库转换；存算分离和存算一体的区别（这些都是老生常谈了）
• 语句方言：不同的数据库是带着很多独特的语句的，有些语句的实现不是那么简单的
• 等等

2 加节点就好

这也是一个朋友跟我说的（经过加工和总结）：

多整点服务器，扩充集群节点数量性能就一定好

还是总结（科普）一下：

• 任何集群节点越多需要管理维护服务器和组件就会相应增加
• 内存本身的延迟是100ns左右，网络都是ms往上，节点多了网络带来的传输性能开销是非常可观的
• 如果节点多到一定程度或者规划原因需要跨网段、跨交换机，那么网络可能带来的波动和延迟会更大

当然还有一个和节点相关的论调：

集群就该奇数节点，偶数节点都是有问题的

集群偶数节点最容易出现的问题就是脑裂，比如四个节点1、2节点和3、4节点相互中断但1、2节点间和3、4节点间又能通信，全局投票就会出现2:2的现象，谁也不服谁，都觉得自己该存活，因此会造成全局不一致。这也是一些数据库的建议中使用奇数节点的原因之一。
当然数据库集群架构已经发展了这么多年了，可在偶数节点上解决这一问题当方案简直多了去了：

• 节点权重：不同节点权重不同，全局不可能出现投票同分现象
• 多网络：在生产、传输网络之外，增加用于管理的网络
• 仲裁节点：在数据库节点外增加独立的仲裁节点
• 存储仲裁：在存算分离架构中，使用存储替代网络进行投票和探活
• 等等

当然上面几种方案组合使用效果更加，但是对于集群自身管理而言也是一种挑战。

3 慢就一定有问题

还是朋友跟我说的（经过加工和总结）：

SQL运行时间长的就一定有问题

等等，这是不考虑数据量、SQL复杂度、业务场景要求等一系列因素啦。数据量越大需要的数据IO越多，耗时自然会更多；SQL越复杂需要关联处理的数据越多，时间越长也是情理之中；如果是OLAP的业务，那么大多数时效性要求也没那么高…
但是不得不说，如果本着精益求精的态度去优化这些语句，节省的可不只是时间，还有相应的各类资源损耗。

总结

2024年最后一次集中吐槽了，希望大家喜欢。
老规矩，不知道写了些啥。